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Preface 


The hydrologic simulation engine (HSE) is a fully integrated groundwater and surface water 
model that can simulate a variety of hydrologic components such as overland flow, canal flow, 
lake storage, infiltration, evaporation, etc. Depending on the type of water bodies and water 
movers used in a model, 2-D overland flow, 2-D or 3-D groundwater flow, canal flow, lake 
flow or any combination of these flows can be simulated using the model. Local hydrology is 
simulated through the use of hydrologic process modules (HPMs), which calculate the local 
water balance on a cell by cell basis. HPMs provide a method to simulate the local surface 
hydrology in a mesh cell or a collection of mesh cells. 
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Chapter 1 


Introduction 


This RSM Version 2.2.9 user’s guide has been written as a companion to the RSM theory 
manual’. The purpose of this manual is to provide information necessary to build an RSM 
model or to modify the input and output of an existing model. New RSM users should consult 
the theory manual to gain an understanding of the conceptual framework upon which RSM 
is built. The theory manual discusses topics such as governing equations, numerical solution 
techniques, Hydrologic Process Modules (HPM’s) and other topics. 


1.1 Programming Information 


The RSM model is a continuously evolving, object-oriented model coded in C++. In May 
2004, RSM version 2.2.2 contained 216 source files (.cc and .h files) with nearly 46,000 lines 
of computer code (comments, blank lines, and active code) with 29,000 lines of active code. 
There were 263 classes, 3,085 functions, 10,976 declarative statements, and 14,764 executable 
statements. About one year later in April 2005, RSM version 2.2.9 contained 245 source files, 
nearly 57,000 lines of computer code, and 32,000 lines of active code. There were 302 classes, 
3,587 functions, 13,368 declarative statements, and 18,441 executable statements. 


The GNU C++ compiler is used on Red Hat Linux 9.0 to create the RSM executable 
used in simulations. The code currently operates only on Red Hat Linux 9.0 and uses at least 
seven external libraries for such items as XML technologies, netcdf files, solver technologies, 
etc. It is possible that future releases of RSM will be made available for the Windows 
operating system. 





‘http: //gwmftp.jacobs.com/manuals/rsmtheoryman.pdf 
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1.1.1 Programming Details 


A variety of code analysis methods have been used to gain an understanding of the RSM 
program structure. The nature of large object-oriented codes can make them difficult to 
comprehend and to visualize. A comprehensive code analysis of RSM 2.2.9 has been com- 
pleted and includes a variety of ways of examining the code. The RSM 2.2.9 reports can be 
viewed here.?. The RSM 2.2.9 source code has also been formatted and placed into a pdf file 
which can be retrieved by selecting the code review item in the source publisher report.®. 


1.2 Howls A Model Solution Achieved? 


A flowchart has been created for RSM to show the sequence of events that occurs during the 
execution of a typical transient RSM simulation The flowchart does not attempt to go into 
full detail of what the program accomplishes, but rather it traces the primary steps taken by 
RSM during the course of running a simulation. Much of the information has been extracted 
from the finite-volume class. The intent of the flow chart is to show a serial pathway taken 
by the code during execution. Of course, not all items in the flowchart are used for every 
simulation and the model input can vary from one application to another. The flowchart is 
displayed in Figure 1.1. 





“http: //gwmftp.jacobs.com/models_2_2-9/hse_2_2.9 html/index.html 
3http://gwmftp.jacobs.com /models_2_2_9/hse_2_2_9_sp/index.html 
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Figure 1.1: RSM model execution flowchart. 
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Chapter 2 


RSM Input Using XML 


RSM data are generated in the self-descriptive file format of Extensible Markup Language 
(XML). This chapter provides an overview of RSM XML input, and is intended for users 
familiar with RSM input files. If you are new to XML input data files, it would be beneficial 
for you to study the XML overview information presented in Appendix B. 


2.1 Introduction 


The hydrologic simulation engine (HSE) is a fully integrated model that can simulate hy- 
drologic components such as overland flow, canal flow, lake storage, seepage, etc. A large 
amount of carefully organized data is needed for the model to simulate a system. Depending 
on the type of water bodies and water movers available, 2-D overland flow, 2-D groundwater 
flow, canal flow, lake flow or any combination of these flow types can be simulated using 
the model. The types of information needed for a model run can be classified into the basic 
categories as described in Table 2.1. 


The model is completely input data driven. Model objects are created as data specified 
in an XML input file are parsed. These objects accumulate and reside until the model run is 
complete. Once the model is finished, the objects are released from computer memory. The 
input data controls the creation of these objects and every aspect of the model run. Once 
the XML input files are built and a simulation is ready to executed, the following command 
is issued on the Linux command line. 


hse filename [-v -1 logfile] 





where filename is the name of the XML input data file. The optional parameter -v 
may be specified to perform XML file syntax validation check without execution of HSE hy- 
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Table 2.1: Basic data types used in HSE. 





Data 


Description 





Setup 


Global parameters, such as start and ending time, time 
step, and solver parameters. 





Main objects 


The basic building blocks for the model, which include: 
2-D water bodies (e.g., cells, canal segments and lakes); 
water movers (e.g., pumps, weirs, etc.); HPMs for land 
use types (e.g., agricultural and urban types). 





Boundary conditions 


Boundary conditions of the model domain. 





Time series 


Time series data needed. 





Object characterizations 


Local micro hydrological model characterizations using 
HPMs, conveyances, transmissivities, etc. 

















Controllers Low-level operational features using controllers are de- 
scribed here. 

Management High-level control of overall management direction of the 
model using LP or other coordination is defined here. 

Output Specifies what is to be output and in what form. In gen- 


eral, any variable in the model can be output for further 
processing. 
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drologic simulation time steps. This check currently is set to compare the input data against 
the Data Type Definition (DTD), not the schema. If users prefer a higher degree of data 
validation, they should execute the schema validation steps outlined in subsection B.3.2. If 
the option -1 is specified with a log file argument, then all console information and error 
messages will be written to the log file. 


HSE can be used as an overland flow model, ground water model, canal network model, 
or a lake model with any number of connecting water movers. Any combination of the water 
bodies is possible, regardless of whether they are connected or not. By default, water in the 
water bodies doesn’t move if there are no water movers with the exception of the default 
horizontal water movers. They are generated automatically once proper geometry files are 
provided. This process takes into account geometrical overlaps and other conditions. Any 
additional water mover has to be defined using input data. The five default water movers 
are: 


e Overland flow water mover moving water between all ponded cells 
e Groundwater flow water mover moving water between ground water cells 


e Canal flow water mover moving water between connecting canal segments 


e Overland flow and canal-flow interaction moves water between cells having overland 
flow and canals 


e Groundwater flow and canal-flow interaction moves water between the groundwater 


cells and canals 


Unless blocked using no-flow boundary conditions, water can flow through all of the five 
default water movers. It is important to note that overland and groundwater flow interaction 
does not happen automatically. The user must specify overbank and seepage parameters. If 
these are not specified, the HSE will not create the associated water movers. 


2.1.1 Naming Conventions 


A number of conventions were used in writing this user’s manual. 





filename name of a file used 





<xml_element_name> | XML elements 





"nnn" xml attribute data values=nnn 














[abc] optional values 
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2.1.2 Software Setup Needed To Run The Model 


The model is currently supported in Red Hat Linux 9.0. The following software environment 
is needed prior to running the model. 


e A statically linked executable or a dynamically linked executable with proper libraries 
and LD_LIBRARY_PATH environment variables set 








e The XML DTD file hse. dtd, with location specified in the main XML file 


e The input XML data file, with the location of the DTD file specified in the 
<!DOCTYPE hse SYSTEM> XML tag 





e Any required model geometry files, canal network files, boundary condition or initial 
condition input files 


2.1.3 Steps And Data Needed To Run The Model 


Significant effort is underway to create an RSM pre-processor that is graphically-based and 
will automate many of the steps required to create RSM applications, as discussed in subsec- 
tion 7.4.2. This pre-processor will directly create XML input data from GIS coverages, for 
example. Current functionality for the pre-processor is described in subsection 7.4.1. The 
general steps required to build a model application are listed below. 


1. Create a triangular cell topographical mesh. Import GIS coverages into GMS or any 
other mesh generator, and create a mesh file in GMS format covering the model domain. 
Certain rules are enforced regarding the cell enumeration and formatting, these rules 
are described in the RSM theory manual (see the Model Stability Guideline Section). 


2. Create mesh physical properties indexed files. This step is currently under development. 
For more information, see section 7.4. 


3. Assemble input/boundary condition files. Obtain all required time-series input files 
required for boundary condition flows, heads, etc. in DSS or NETCDF formats. 


4. Assemble input XML model definition files. This manual details the XML file syntax 
used as input to RSM. 


5. Execute the model. XML syntax and content validation errors will be written to the 
file xml.errors. Time step execution information will optionally be echoed to the 
command terminal, linear system solver monitors will optionally be displayed in X- 
windows. 


CHAPTER 2. RSM INPUT USING XML 13 


6. Post-process model results. After running RSM, the output data created can be viewed 
using HECDSSVUE, TECPLOT, IBM Data Explorer or even ARCVIEW. Python- 
based post-processing utilities are described in subsection 7.4.1 and subsection 7.4.2 


2.1.4 HSE Specification Using XML 


All XML style specifications are contained in the XML simulation file. All RSM XML 
documents begin with processing instructions given by the first three lines in the example 
below. If the RSM schema is used to validate the input as discussed in subsection B.3.2, you 
will have to change the file back to the following format because the RSM source code and 
XML libraries have not yet been updated to utilize a XML schema document type. 





<?xml version="1.0"?> <!DOCTYPE hse SYSTEM "../hse.dtd" [ 
<!ENTITY HPMs SYSTEM "pseudo.xml"> <!ENTITY landscape 
SYSTEM "landscape.xml"> ]> <hse version="0.1"> 

<control 
tslen="24" 


























These lines explicitly identify an XML document and indicate which version of XML 
was used. The name and the location of the DTD file is also indicated here. The content of 
the XML file creates a tree-like hierarchy of information. The uppermost <hse> element is 
termed the root element. All other elements are children of <hse>. Elements specific to the 
HSE, e.g. water movers, lakes and ponds, lake seepage, model output and HPMs are nested 
within the root element named <hse>. A list of first-order children elements possible under 
the <hse> root element is given in Table 2.2 and depicted in Figure 2.1. 


A “well-formed” XML for the HSE would look like: 








<?xml version="1.0"?> <!DOCTYPE hse SYSTEM "../hse.dtd" [ ]> 
<hse version=**0.1’'> 

<control> ... </control> 

<mesh> ... </mesh> 

<network> ... </network> 

<watermovers> .. </watermovers> 

<controller> ... </controller> 

<management> ... </management> 
</hse> 


where the ”hse” version attribute is used to ensure consistency between input specifica- 
tions and version of HSE (not yet implemented). Space covering the dotted lines has to be 
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Table 2.2: Definition of elements defined in the <hse> root element. 









































Tag Definition 

<control> All the program control parameters such as time step 
size, beginning time, ending time, etc. are defined using 
this XML element. See Table 3.1 for specific information. 

<mesh> Information regarding the 2-D mesh are defined within 
this XML element. See Table 3.3 for specific information. 

<network> Information regarding the canal network are defined 
within this XML element. See Table 3.3 for specific in- 
formation. 

<watermovers> | Water movers such as structures are defined here. 

<lakes> Lakes and ponds water bodies are defined here 

<multilayer> | Information about 3-D or multi-layered groundwater is 
defined here. 

<controller> | Information about controllers are provided here. 

<management> | Information about management supervisors is defined 
here. 

<output> Specifying model output. 

<rulecurves> | Information on watermover control rule curves. 

<basins> Not fully implemented in this version. 
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filled with other elements or attributes to be described later. Details and examples are given 
in the later chapters, the HSE benchmarks also provide numerous examples of HSE XML 
file usage. If any components are not present in the model, they can be skipped. 


2.1.5 XML Elements Under The Root 


All the model details are provided under the above-mentioned first-order children elements 
listed in the XML file. The dots in the XML simulation file shown above represent real 
information. A brief description of some of the children elements is given in this section. 
Remaining elements such as the <mesh> element that require more information will be 
described in section 3.2. 


2.2 Suggested Development Procedure for Applications 


To reduce errors, it is convenient to build models up from a very basic overland flow model or 
a canal flow model, and gradually add features. It is easy to detect errors this way because 
the last component to be added is most likely to have caused the problem. When errors 
occur at any time, one of the methods of diagnosis involves taking out the RSM objects one 
at a time until the model starts to respond accurately. Commenting out lines in the XML 
file is an easy method to search for errors. 


The majority of errors associated with running RSM are due to missing, incorrect, or 
mal-formed input data. If the problem is one of missing or extra data elements in the XML, 
the DTD syntax validation will create an error report named xml.errors. The schema 
validation methods will uncover more difficult to find data errors. If the XML data set passes 
the schema validation, it will run in RSM. However if the data problems are due to data 
falling outside a valid range of input, the schema validation routine is not yet completed at 
this level to catch this type of problem. The user has to be careful to make sure that the 
data are pre-processed to accurately reflect the physical parameters of the modeled domain. 


2.2.1 Sequence Of Object Creation 


RSM objects are created in a certain sequence partly for historical reasons, and partly 
because of the C++ object inheritance present in RSM. Therefore, the data set sequence 
is important because certain objects can be created only after other objects are created. It 
is safe to follow the XML data input ordering contained in the benchmarks to eliminate 
errors related to the ordering of the XML data. The first-order children elements should be 
arranged in the sequence that is shown in Figure 2.1. The sequencing of children elements 
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that are nested beneath these are also diagrammed and can be viewed by navigating through 
the on-line data input guide.! 

e The output sub-elements are shown in Figure 2.10. 

e The control sub-elements are shown in Figure 2.2. 

e The mesh sub-elements are shown in Figure 2.3. 

e The network sub-elements are shown in Figure 2.4. 

e The watermovers sub-elements are shown in Figure 2.5. 

e The controller sub-elements are shown in Figure 2.8. 

e The management attributes are shown in Figure 2.9. 

e The rulecurves KCB add. 

e The tsNodes KCB add. 

e The lakes sub-elements are shown in Figure 2.6. 

e The basins KCB add. 

e The assessors KCB add. 

e The mse network KCB add. 

e The streambanks KCB add. 


e The multilayer sub-elements are shown in Figure 2.7. 


2.3 RSM Directory Structure 


The directory structure of RSM is organized as follows: 


e hse - top level directory containing RSM 
e benchmarks - test cases and hse.dtd file 


e budtool - water budget tool 





‘http: //gwmftp.jacobs.com/xml_schema_corrected/graphics/hse_222.html 
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e doc - documentation 


e fcl_lib - fuzzy control library 


glop - GNU linear programming kit library 


psbud - HPM water budget package 


e src - source code and executable 


2.3.1 RSM Benchmarks 


HSE incorporates a suite of standard benchmark tests to provide quality assurance and 
validation of new features added to the model. There are over 60 benchmarks. The individual 
benchmarks reside in subdirectories of the hse/benchmarks/ such as BM1, BM2, etc. To 
run the benchmark suite, the user can perform the following commands from the hse root 
directory: 


cd benchmarks 
./test.script 


The benchmarks can serve as a valuable training resource for the novice modeler. Most 
of the main features of the RSM are exercised in the benchmarks (see the Benchmark and 
Verification Manual for more details). A complete listing of all benchmarks described in 
detail is available here?. The most up-to-date description for your RSM release can be 
obtained by processing the benchmarks/descriptions.tex file with the tex or ATX program. 





“http: //gwmftp.jacobs.com/benchmarks/bm_des.pdf 
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El attributes 


version 


[xs:string | 
[required | 





Basic model timing and solver parameters, 


Creates the environment to enter the 2D mesh attributes, 


tee__t 
This is the root element of HSE (Hydrologic Simulation Engine) = s = 
Creates the environment so that a canal network can be specified, 


Creates the environment for specifying watermover hydrologic objects such as 
physical hydraulic structures, 


Used to define lake and pond water bodies, 


“EE 
=f 


1.. 3D groundwater Aow using multiple layers, 





MSE management environment that allows the definition of supervisors, 


RSM output options, 


,rulecurves 


Rule curves describe variables that vary during a year and then repeats that behavior 





|,zbasins 


Basin definition. Current not fully implemented in this version. 


Figure 2.1: The HSE root node and first-order children elements. 
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E attributes 


g time ( starttinn ) 








g date (startdate="01jan1965" ) 











matted ending date ( enddate="3 














explicit; 0.5 to 0,75 are typical values 








: solver 
xs:string 
optional 

it |PETSC 





; method 
xs:string 
optional 

it [begs 





odel timing and 








er parameters 


can be activated 





, either english or metric 


ady state = 0 


xs:string 
none 









of prerunning of the simulation. 


Nurnber 








controllers y 
xsistring | 


llers are on o 








are on or off, 











Figure 2.2: The control subelements. 
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geometry 


Specifies multipliers for the grid and cross-sectional watiables, 


zmesh_be 


Creates the environment to enter the 2D mesh boundary conditions. 


The cell heads at the beginning of the simulation are specified under this element. 


arain 


Creates the environment for assignment of rainfall on each mesh cell, 


prefet  Ę 


Indicates that the reference ET is specified. 


zbottom  Ę 


Bottom elewation of a cell, 


environment for specifying the ground surface elewation of each cell 
). 


Creates the environment to enter the 2D mesh attributes, 






,zpseudocell 


Creates the environment for assignment of HPM types to mesh cells, 


Defines 


t 





omputational approach for overland Aow and defines conveyance objects, 


eà 


or specifying the transmissivity for groundwater Aow 
ailble through indexed and entry pathway. 


es the environment fi 
is, Additional op 










pro 


,vert_conductivity 


Specifies the vertical hydraulic conductivity of a cell. 


Adds vertical hydraulic conductivity resistance Factor to cells for multi-dimensional 






he environment for specifying the stagevolume of water storage relationship 





1 cell, 


Figure 2.3: The mesh subelements. 
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Specifies canal network boundary conditions, 


Figure 2.4: The network subelements. 
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specifying watermo 





|a Single_control 


ifies a lookup table containing the relationshop between head and discharge 


er that all 











Water -difference 











javnotchbleeder 


Defines a w-notch bleeder borrowed from MBR. 


(a circularbleeder 


cular ble borrowe: 





jarectbleeder 


jer borrow 





om MBR 





angular ble 


Pipe water mover borrowed from MBR 


Culvert water mover borrowed from National Weather 


Defines a bro. 


Defines a sharp-cr 


fines a drop weir that simulates a moming gl 
pipe with water Rowing over the lip 








d-crested weir that is wed from the MBR model 








i the MBR 





eir that is borov 








ry spillway, which is a vertical 








Watermover that si 


bodies 








ecify the flo 


Simulates a hydropower plant placed bety 


Watermover that sp 


Sp 


Bridge routine based on 
Reference Manual, 


water in or out of a water body 


n two water bodies, 








jes flow through a gated weir. 


VWM FLDWAY Manual 





y water m 








nell equations derived from the HECR: 





watermover, 


Figure 2.5: The watermovers subelements. 
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Figure 2.6: The lakes subelements. 
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muye È co.: 


3D groundwater Aow using multiple layers, Used to input data For multilayer simulations, 


Figure 2.7: The multilayer subelements. 
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E attributes 

















abilit 
red o 


nown thresho 


nent operational 
simple rules and binary 








MSE (Management Simulation Engine) controller objects, 


a watermover may have no physical 


fow, 


The LP con to control of 


a waterm 


(glpk_supery 












nming Kit (GLP 


J. It contains no control algorithm and processes no state information, 





Condition-action controller which is a rule based controller patterned after the ORM 
model, 


Figure 2.8: The controller subelements. 
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Figure 2.9: The management attributes. 
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Output monitor used to capture all values of a variable for the entire simulation, 


Useful in monitoring a large number of attributes, 


Used to monitor lake properti 


Useful in monitoring a large numbe 


Used to monitor Aow at canal junctions. 


2wmmonitor E 


Useful in monitoring water movers. 


jzbemonitor EF 





of segment attributes, 








Used to monitor boundary c 










vimnonitor environment to fed to the 


> monitor output values ge 


Used to monitor 
be updated in the 


Used to monitor basins, May currently be in a state of change, this element will have 
to be updated in the future, 


Useful in monitoring attributes within the HPMs, 


Useful for monitoring Aow across Aow lines. 


budget 


ifies water budget output file, 


-cellreport 


ifies the 






onitor input stat 
rated by supery 








Currently in a state of change, this element will have to 














orting output file. 


~ psbudgetpackage 


enient way to output all 
HPM budget. 


; budgetpackage 


Outputs all nec 









ry components to do a 








components to do a post-proce waterbody budget, 


Figure 2.10: The output subelements. 


Chapter 3 


HSE Model Components and XML Input 


This chapter contains details of the model components (i.e., hydrologic objects) and the 
XML instructions that represent these objects. There are over 200 XML elements and over 
700 attributes corresponding to these elements that are supported in Version 2.2.2 of the 
model. Details are provided for the XML input of each object. The functional, but not fully 
implemented 3D groundwater flow input requirements, are presented in Appendix C. 


28 


CHAPTER 3. HSE MODEL COMPONENTS AND XML INPUT 29 


3.1 Basic Model Set-Up Parameters - The XML <control> Ele- 
ment 


The XML <control> element is used to define the basic model set-up parameters, which 
includes a variety of terms related to time stepping, solver choices, and other topics. Table 3.1 
contains the XML attributes used within the <control> element. The order of placement 
of the tags inside the <control> element is not important. If not specified, some defaults 
will be assigned as shown in the on-line data input guide.' The default values are shown for 
attributes such as alpha and solver. 





‘http: //gwmftp.jacobs.com/xml_schema._corrected/graphics/hse_222.html#element_control_Link03048EC8 


Table 3.1: Attributes defined with the XML <control> element. 
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Attribute Definition Dimen- | Variable | Suggested range Default | Example 
sions type 
starttime Starting time of the | NA DSS 0000 to 2359 Req. starttime="2315" 
simulation format 
hhmm 
endt ime Ending time of the | NA DSS 0000 to 2359 Req. endtime="0120" 
simulation format 
hhmm 
tslen Timestep length T Integer >0 Req. tslen="24" 
tstype Timestep unit NA String Second, minute, Req. tstype="hour" 
hour, day, week 
startdate Starting date of the | NA DSS for- | Any valid date Req. startdate 
simulation mat ddm- ="01jan1994" 
mmyyyy 
enddate Ending date of the | NA DSS for- | Any valid date Req. enddate 
simulation mat ddm- ="30jan1994" 
mmyyyy 
alpha Time weighting fac- | NA Real 1.0 = implicit, 0.5 = | Req. alpha="0.75" 
tor mid, 0.0 = explicit 
solver Sparse solver name | NA String PETSC is the only op- | Req. solver="PETSC" 
tion 
method Sparse solver | NA String See PETSC manual Req. method="gmres" 
method 
precond Pre-conditioner NA String See PETSC manual Req. precond="bjacobi" 
nt Number of time | NA Integer Any integer 10 nt="10" 
steps to be simu- 
lated. Steady state 
=0 
units Model units NA String ” METRIC”, ”EN- | METRIC) units="english" 
GLISH” is optional 
petscplot Solver monitors NA String ” ” | none petscplot="all" 














” all” 














Table 3.1 continued on next page 
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Attribute Definition Dimen- | Variable | Suggested range Default | Example 
sions type 
preRunType Used to specify the | NA String Options include ”con- | none preRunType ="none" 
type of pre-running troller”, ”filter”, ” all”, 
of the simulation. ” none” 
preRun- Number of itera- | NA Integer Any integer, defaults to | 0 preRunIterations 
Iterations tions used during 0. ="0" 
the pre-run. 
controllers Activate controllers | NA String ”on” or ” off” on controllers="on" 
supervisors Activate supervi- | NA String ”on” or ” off” on supervisors="on" 
sors 
runDescriptor | Brief description of | NA String Any String none runDescriptor="NSRSM 
simulation V2.0" 
defDBintl Default database | T Integer Time interval in min- | 0 defDBint1l="1440" 
interval in DSS files utes 
plotintvl Number of time | NA Integer 0 to 100 0 3 








steps between plots 























NA = Not Applicable; Req. =Required 
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An example of a data definition used with a <control> keyword is shown below. 


<control 
tslen="15" 
tstype="minute" 
startdate="01jan1994" 
starttime="0000" 
enddate="01janl1994" 
endtime="0230" 
alpha="0.500" 
solver="PETSC" 
method="gmres" 
precond="ilu"> 

</control> 


3.1.1 Model Units 


By default the model uses SI units. However, input data in English units can be used by 
entering the attribute units="english" as described in Table 3.1. Any other system of 
units can be implemented by using optional multipliers as described later. Some of the units 
and data types used with the DSS file format are described in Table 3.2. 
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Table 3.2: Default units used by HSE. 












































Quantity Unit Type 

Head METERS INST-VAL 

Flow CU_METER/SEC INST-VAL 

Rain METERS PER-CUM 

ET METERS /time step PER-CUM 
Depth METERS INST-VAL 
Water level METER INST-VAL 
Transmissivity | METER?/SECOND PER-AVER 
Definition of Available Unit Types 

Type Definition Example 
PER-AVER Period Average Daily flow 
PER-CUM Period Cumulative Monthly flow (volume) 
INST-VAL Instantaneous Breakpoint Stage 








INST-CUM 





Instantaneous Cumulative 





Rain mass curve 
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3.2 Data For The Two-Dimensional Model <mesh> 


Setting up the basic two-dimensional regional model requires geometric input data to describe 
sizes, shapes, locations of cells, and elevations of the bottom and the ground surface of each 
cell. Additional information to characterize the hydrologic properties of each cell includes the 
relationship between head and volume of water stored, the description of groundwater and 
surface water flow properties and mechanisms, and the description of the local hydrologic 
processes for each cell from the assignment of a HPM to each mesh cell. The remaining data 
under the <mesh> element are the forcing functions that drive the regional flow. These 
are boundary conditions for the cells and the walls that divide the cells, and rainfall and 
evapotranspiration used by HPMs, which in turn produce a forcing function on the mesh. 


Data for the 2-D model is entered in the <mesh> environment. These data are described 
in detail in subsequent sections. The elements under which these data are input are listed 
in Table 3.3, Table 3.4, and Table 3.5. Table 3.3 describes how to specify the 2-D geometry 
file that specifies the node locations. The elements listed in Table 3.4 describe data that are 
explained in greater detail in later sections, and Table 3.5 lists additional data that are read 
from data files and the file formats available. The attributes needed to describe the data 
input for the elements in Table 3.5 are listed in Table 6.1 and Table 6.5. 


Table 3.3: Specification of the geometry file under <mesh>. 














<Element> Definition Dimensions | Variable Suggested Default | Example 
or Attribute type range 
<geometry> Creates the environment to specify a geometry file in GMS 
format. 
file The name of the file NA String Any valid GMS | Req. enp.gms 
file name 
mult Multiplier for mesh node co- | NA Real Any valid real | 1.0 0.3048 





ordinates, often for unit con- 
version 























Details of the GMS file are explained in section 3.3. NA = Not Applicable; Req. = Required 
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3.2.1 Attributes of the Data File Formats Used In The <mesh> Environment 


Under the <indexed> element entries can be defined as described in Table 3.6. Each entry 
specifies an input, in this case a time series, rule curve, or constant. These inputs may 
be applied to cells using an index file in which each cell is assigned an index number to 
specify which input is associated with each cell. The indexing concept has more general 
application as described throughout this manual. For example the indexing method may be 
used to assign HPMs to mesh cells or hydraulic properties to canal segments. Other formats 
for assigning input data to the cells in the mesh are <gridio>, <gms> and <netcdf>. 
Formats for <indexed>, <gridio>, <gms> and <netcdf> and the attributes are shown 
in Table 3.6, Table 3.7, Table 3.8, and Table 3.9. Examples are shown later in this section. 
Format and attributes for <const> and <dss> are explained in chapter 6. 


Data in a <gridio> file are referenced to the xorig and yorig attributes in Table 3.7. The 
height and width of each grid cell are specified in the file along with data values associated 
with a row number and column number. By specifying xorig and yorig as shown in Figure 3.1 
the data are assigned to locations at the centers of the appropriate cells. The model then 
interpolates these data to assign values to the triangular mesh cells. 
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Table 3.4: Additional mesh elements. 
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Element 


Definition 


Available subelements 





<transmissivity> 





The element under which trans- 
missivity for groundwater flow 
is specified. The confined_gms, 
confined_gms_layer, and lay- 
ered_gms_layer elements are available 
only under the indexed and entry 
pathway. Details are given in 
subsection 3.4.2 


<indexed> 
<confined> 
<confined_gms> 
<confined_gms_layer> 
<layered> 
<layered_gms_layer> 
<lookuptr> 
<unconfined> 
<unconfined_gms> 





<unconfined_gms_layer> 

















<conveyance> Creates the environment for specify- | <indexed> <manning> 
ing the calculation of conveyance for | <cadlec> <layerc> 
overland flow. Details are given in | <lookup> 
subsection 3.4.1 
<svconverter> Creates the environment for specify- | <indexed> <constsv> 
ing the stage-volume of water storage | <lookupsv> <layersv> 
relationship for each cell. Details are 
given in section 3.8 
<HPM> Assignment of HPM types to mesh | <indexed> <layer5> 
cells are made under this element. | <layerlnsm> <nam> 
Details are given in chapter 5 <unsat> <mbrcell> 
<afsirs> <layerpc> 
<hub> 
<mesh_bc> Creates the environment to specify | <we11> <cellhead> 
the mesh boundary conditions for | <cellghb> <wallhead> 
cells and walls. Details are given in | <wallghb> <noflow> 
chapter 4 <walluf> 
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Table 3.5: Elements for specifying input formats for additional mesh properties under <mesh>. 























Element Definition Available 
input for- 
mats 

<bottom> Creates the environment for specifying the bottom | <indexed> 

elevation of each cell (NGVD or NAVD). <const > 
<gms> 
<surface> Creates the environment for specifying the ground | <indexed> 
surface elevation of each cell (NGVD or NAVD). | <const> 
<gms> 
<shead> The cell heads at the beginning of the simulation | <indexed> 
are specified under this element. <const> 
<gms> 
<rain> The rainfall on each cell during the simulation is | <indexed> 
specified in this environment. <const> 
<dss> 
<gridio> 
<netcdf> 
<gms> 
<refet> The reference crop potential evapotranspiration | <indexed> 
for each cell during the simulation is specified in | <const> 
this environment. <dss> 
<gridio> 
<netcdf> 








<gms> 
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Figure 3.1: <gridio> file geometry 


col = 1 


X = Xorig + 2AX 
Y = Yorig + 3AY 


row = 3 


row =2 


row = 1 


i 





-a 


(Xorig, Yorig) i 
AX AX 
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Table 3.6: Elements and attributes used with the <indexed> element. 









































<Element> Definition Dimensions Variable| Suggested Default | Example 

or Attribute type range 

file name of the index file NA String A valid file | Req. refet 
name _index.dat 

<entry> Creates environment for entry data. 

id Entry ID number NA Integer | Any integer Req. 0 

<const> A constant value option 

<dss> A DSS option 

<re> A rule curve option. See subsection 6.1.2 





Details of the <dss>, <const>, and <rc> formats are described in chapter 6. 








NA = Not Applicable; Req. = Required. 
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Table 3.7: Attributes used with <gridio>. 




















Attribute Definition Dimensions | Variable Suggested range | Default | Example 
type 
file Name of the file NA String A valid gridio file | Req. rain.dat 
name 

dbintl Database interval used | T Integer | -1 for steady state | 1440 1440. 
in the gridio file (min- or > 0 
utes) 

xorig X co-ordinate of the | L Real Any real Req. 543329 
origin 

yorig Y co-ordinate of the | L Real Any real Req. 286761 
origin 

mult Multiplier for the data. | NA Real Any real 1.0 0.0254 


























NA = Not Applicable; Req. = Required. 
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Table 3.8: Attributes used with <gms>. 











Attribute Definition Dimensions | Variable | Suggested range | Default | Example 
type 
file Name of the GMS file | NA String A valid GMS file | Req. enp.gms 
name 
mult Multiplier for the | NA Real Any real 1.0 0.3048 








data values, often 
used for conversion 
between metric and 
English units 























NA = Not Applicable; Req. = Required 
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Table 3.9: Attributes used with <netcdEf>. 




















Attribute Definition Dimensions | Variable | Suggested range | Default | Example 
type 
file Name of the netcdf file | NA String A valid netcdf file | Req. coast.dat 
name 
variable | Name of the variable | NA String A valid variable | No rain 
name default 
dbintl Database interval used | T Integer > 0 -1 1440 
in the netcdf file (min- 
utes) 
mult Multiplier for the data | NA Real Any real 1.0 0.3048 
values 
units Units of the variable NA String Any string Imp. meters 


























NA = Not Applicable; Req. = Required; Imp. = Implied 
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Certain basic types of data are required for a model run. In the case of 2-D flow, all 
the information about 2-D cells listed in Table 3.3, Table 3.4 and Table 3.5 are needed 
to describe all cells fully. User specified water movers such as physical structures may be 
needed depending on the system being simulated. When a model is constructed, it is better 
to assemble the components a few at a time, so that the evolution can be followed, and bugs 
detected as early as possible and fixed in a systematic way before they become too numerous. 
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3.2.1.1 Examples Of 2-D Data Defined Within <mesh> 


The following examples demonstrate the use of modifiers to describe a variety of data sources. 
In the following example, the geometry file is specified with the multiplier omitted with a 
default of 1.0, the initial heads are read from a GMS file with a default time interval of 
1440 minutes and a multiplier of 1.0. The ground surface elevation is input as a constant 
value of 50 meters, the transmissivity is of the confined type with a value of 0.04 m?/s 
and <svconverter> uses a constant storage coefficient of 0.2. The <svconverter> is 
explained in section 3.8. 


<geometry file="mesh3x3.2dm"> </geometry> 
<shead><gms file="hin3x3.dat"></gms></shead> 
<bottom> <const value="0.0"> </const> </bottom> 
<surface> <const value="50.0"> </const> </surface> 
<conveyance> 

<mannings a="1.000" detent="0.00001"></mannings> 
</conveyance> 
<transmissivity> 

<confined trans ="0.04"></confined> 
</transmissivity> 
<svconverter> 

<constsv sc="0.2"></constsv> 
</svconverter> 





In the example below the rainfall data file sfrain_v1.2.bin is in binary gridio for- 
mat, with an x and y origin (543329, 286761) of the gridio input file. The time step is one 
day (1440 minutes) and the multiplier converts inches to meters. 


<refet> 
<gridio file="/vol/hsm/data/db/grid_io/rain/sfrain_vl.2.bin" 
xorig="543329" yorig="286761" mult="0.0254" dbintl="1440"> 
</gridio> 
</refet> 


If the ET data are to be presented in the <dss> format, the following example shows a 
segment of the input XML file. 


























<refet> 
<dss file="rainET.dss" 
pn = "/S8/Areal/REFET/01JAN1994/1DAY/Estimated/" 
mult="0.0254" dbintl="1440"> 
</dss> 
</refet> 


If unconfined flow is to be specified, with hydraulic conductivity, k = 0.02 m/sec the follow- 
ing XML input may be used. 


<transmissivity> 
<unconfined k = "0.02"> </unconfined> 
</transmissivity> 
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3.3 Two-Dimensional Grid Data <geometry> 


Geometry data for the two-dimensional overland flow/groundwater flow model are described 
in this chapter. These data consist of the (x,y) coordinates of each node and the node 
connectivity. Each cell is numbered and the nodes that the define each cell are associated 
with the cell. The geometry file for HSE can be created graphically using the GMS package. 
The resulting GMS file does not need much modification. The name of the geometry file 
is entered in the <mesh> environment using the <geometry> element. An example XML 
input for specifying the GMS file is displayed below. The file name is L8mesh.2dm and a 
multiplier of 0.3048 is specified to convert feet to meters. 


<?xmll version="1.0"?> <!DOCTYPE hse SYSTEM "../hse.dtd"[ ]> 
<hse version="0.1"> 

<geometry file="L8mesh.2dm" mult="0.3048"> 

</geometry> 








</hse> 


A small sample mesh (mesh3x3.2dm) is shown in Figure 3.2 with cells and nodes num- 
bered. A GMS file that describes the mesh is shown in Table 3.10. The mesh consists of 16 
nodes and 18 cells with the equilateral leg of each mesh cell 5000 m long. This is the typical 
mesh used in the benchmarks and model testing chapter. 


The first line of the GMS file must be MESH2D. Each line that describes the node 
connectivity begins with E3T and each line describing the node locations begins with ND. 
The format of the node connectivity information is 


E3T IC N1 N2 N3 NN 








where, IC is the cell number and N1, N2, N3 are the nodes defining cell IC in a counter- 
clockwise direction. NN is not currently used in the model. After the connectivity is defined, 
nodal coordinates are defined using the format 


ND IN X Y Z 








where, ND designates that these are nodal coordinates, IN is the node number, and X and 
Y are the coordinates of the node. The last entry, Z, is not used in the 2-D model and is set 
equal to 0.0. 


As an example, in this mesh, cell 12 is defined by nodes 3, 7, and 8 and the coordinates 
of node 7 are x = 10000.000, y = 10000.00. 
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Table 3.10: two-dimensional GMS mesh data file "mesh3x3.2dm". 

























































































MESH2D 

E3 1 1 6 2 

E3 2 2 7 3 

E3 3 3 8 4 

E3 4 5 10 6 

E3 5 6 11 7 

E3 6 7 12 8 

E3 7 9 14 10 

E3 8 10 15 11 

E3 9 11 16 12 

E3 10 1 5 6 

E3 1. 2 6 7 

E3 12 3 7 8 

E3 13 5 9 10 

E3 14 6 10 11 

E3 15 7 11 12 

E3 16 9 13 14 

E3 137 10 14 15 

E3 18 11 15 16 1 
ND 1 0.000 15000.000 0. 
ND 2 5000.000 15000.000 0. 
ND 3 10000.000 15000.000 0. 
ND 4 15000.000 15000.000 0. 
ND 5 0.000 10000.000 0. 
ND 6 5000.000 10000.000 0. 
ND 7 10000.000 10000.000 0. 
ND 8 15000.000 10000.000 0. 
ND 9 0.000 5000.000 0. 
ND 10 5000.000 5000.000 0. 
ND 11 10000.000 5000.000 0. 
ND 12 15000.000 5000.000 0. 
ND 13 0.000 0.000 0. 
ND 14 5000.000 0.000 0. 
ND 15 10000.000 0.000 0. 
ND 16 15000.000 0.000 0. 
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Figure 3.2: Discretization of a square area into 18 cells with 16 nodes. (See Table 6.10). 
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3.4 Alternative Forms Of 2-D Flow Equations 


Different equations of overland flow may be appropriate for different regions of the model 
domain. Overland flow is described in the model under the <conveyance> element and, 
and groundwater flow is described under <transmissivity>. For example, flow through 
wetlands is different from flow across a golf course or a ridge and slough area. While Man- 
ning’s equation is used most often, other formulations of overland flow are available in the 
HSE. 


3.4.1 Overland Flow Options 


In an integrated model, overland and groundwater flows are modeled together. In the formu- 
lation used in HSE, these flows can be separated. Overland flow is commonly characterized 
as conveyance. Manning’s equation, which is valid mostly under turbulent flow conditions, 
is often utilized. For overland flow 


Heys (3.1) 


n 


Q 


where 

L = length of the flow face perpendicular to the flow direction, 
n = Manning’s coefficient, 

d = water depth, and 

S = water surface slope. 


It is well known that the appropriate value of Manning’s n decreases with the depth of water. 
When a thick layer of vegetation is present Manning’s n can be quite large for shallow flow 
but decrease significantly with flow depth. One way to improve the accuracy of Manning’s 
equation is to represent n as 

n = Ad? (3.2) 


where 
d = water depth, and 
A and B = empirical constants. 


This modification to Manning’s equation is still not sufficient under many wetland conditions 
with thick vegetation. In this case, another power law equation can be used to replace 
Manning’s equation. Under laminar or transition flow conditions found in wetlands, the V/S 
term needs to be replaced by S% where a is a user-defined exponent. The form used by 
(Kadlec and Knight, 1996) gives 

Q = Lado" (3.3) 
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where 

Q = volume flow rate, 

L = width of flow, 

d = flow depth, and 

a, a and @ = empirical constants. 


A general form of this equation uses a lookup table to describe the behavior of conveyance 
with depth, assuming a can be considered as constant. Flow volume is then computed as 


Q = LO(d)s* (3.4) 


where, C(d) is a lookup table that describes the variation of conveyance with depth. This 
is a useful approach for simulating the effects of microtopography found in the ridge and 
slough formations (Figure 3.3). In these areas the effect of the significant relief of the 
ground surface and the nature of the vegetation makes Manning’s equation (Equation 3.1) 
or Kadlec’s equation (Equation 3.3) (Kadlec and Knight, 1996) inappropriate. To construct 
the lookup table, the average land surface elevation of a cell is specified as well as two other 
elevations. The elevation H = Zło in Figure 3.3 is defined as the elevation at which overland 
flow will begin. Elevation H > zp; is the elevation at which the flow can be assumed to be 
turbulent, and Manning’s equation with S'/? becomes valid. When the water level is below 
H = zp, there is no overland flow. In the range ziņo < H < zp;, Equation 3.4 is used. 


3.4.1.1 Conveyance Type <mannings> 


Data for conveyance are entered within the <mesh> environment under the <conveyance> 
element. The environments available under <conveyance> are described in Table 3.11. 
They can be used to assign conveyance values by 


e Assigning any of the conveyance formulations to the entire model domain. 


e Assigning different formulations <mannings>, <lookup>, <cadlec> to different 
parts of the model domain using an index file to specify the distribution. 
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Figure 3.3: Definition sketch for using lookup tables for transmissivity and conveyance. 
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Table 3.11: Elements and attributes under <conveyance>. 


LAdNI TWX UNV SINANOdWOO TACOW HSH ‘€ YLdVHO 


e9 

































































<Element> | Definition Dimensions | Variable) Suggested Default | Example 

or Attribute type range 

compute Describes methods of computing average conveyance between mixed 
cells. Details are described in Table 3.12. 

<indexed> | Indicates that conveyance methods are specified under 
<entry> and assigned to cells with an index file. 

<mannings> | The Manning equation is used and the roughness coefficient is defined as n = 
A(depth)?. 

a The coefficient A in Equa- | NA Real > 0.0 Req. 0.5 
tion 3.2 

b The exponent B in Equa- | NA Real > 0.0 0 0.1 
tion 3.2 

detent Minimum value of d in | L Real > 0.0 Req 0.1 
Equation 3.2. The value of 
d is MAX(d,detent). (me- 
ters) 

<cadlec> The conveyance is computed from Kadlec’s equation 3.3. 

a The coefficient a in Equa- | NA Real > 0.0 Req. 0.5 
tion 3.3 

b The exponent @ in Equa- | NA Real > 0.0 Req. 0.1 
tion 3.3 

beta The exponent @ in Equa- | NA Real > 0.0 Req. 0.1 
tion 3.3 

detent Water depth below which | L Real > 0.0 Req. 0.1 
there is no flow (meters) 

<lookup> The conveyance is read from a lookup table. 

below The depth below the ”sur- | L Real > 0.0 Req. 0.1 
veyor’s” land surface below 
which overland flow ceases 
(meters) 

above The depth above the ”sur- | L Real > 0.0 Req 0.1 





veyor’s” land surface above 
which the Manning equa- 
tion applies (meters) 























Table 3.1 continued on next page 
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<Element> | Definition Dimensions | Variable) Suggested Default | Example 
or Attribute type range 
base The parameter A in the | NA Real > 0.0 Req. 0.1 
equation for the Manning’s 
roughness coefficient 
expon The parameter B in the | NA Real > 0.0 Req. 0.1 
equation for the Manning’s 
roughness coefficient 
<convey> A lookup table of depth | NA Real > 0.0 No 0.1 
and conveyance for the default 





range between (land sur- 
face - below) and (land sur- 
face + above) 























NA = Not Applicable; Req. = Required. 
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An example of the XML input required to assign a <mannings> type conveyance to 
different zones of the model domain is shown below. In this example, Manning’s equation is 
used to compute conveyance with the value of the roughness coefficient computed as 


n = 0.540 (3.5) 
with the conveyance = 0 for water depths less than 0.01 m, or by 
n = 0.4406 (3.6) 


with conveyance = 0 for depth less than 0.02 m. The zones where each of the two values for 
n are applied is defined by the index file, lu.index. Using an index file, the conveyance over a 
large region of the model domain may be changed by changing one entry under <indexed>. 


<conveyance> 
<indexed file="lu.index"> 
<entry id="1" label="typel"> 
<mannings a="0.5" b="-0.77" detent="0.01"> 
</mannings> 
</entry> 
<entry id="2" label="type2"> 
<mannings a="0.4" b="-0.63" detent="0.02"> 
</mannings> 
</entry> 
</indexed> 
</conveyance> 








3.4.1.2 Conveyance Type <cadlec> 


The method can be assigned to the entire model domain with the XML example below. 


<conveyance> 
<cadlec a="2.0E6" b="3.0" beta = "0.6" detent="0.01"> 
</cadlec> 

</conveyance> 





In this case, discharge is computed as 


Q = L(2.0110°))a5°* for d> 0.01 (3.7) 


Q=0ifd<0.01 


where L = the length of the wall through which flow occurs, and d = depth of flow. The 
<cadlec> conveyance option is also used in benchmark 38. 
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3.4.1.3 Conveyance Type <lookup> 


This method allows the conveyance to be read from lookup tables based on field measure- 
ments or other sources. The equation for overland flow is 


Q = LC(d)s° (3.8) 


where C(d) = a lookup table function of conveyance versus depth and S = slope. This 
equation applies between the elevations (Land Surface - below) and (Land Surface + above). 
Below this range there is no overland flow and above this range the Manning equation is 
used. In the following example and in benchmark 36, Manning’s equation is used over the 
portion of the model domain where the index file specifies index id = 1. Where index id = 2 
is specified, overland flow is computed from the conveyance in a lookup table specified within 
the environment <convey> for the range of heads between (Land Surface - 10) and (Land 
Surface + 30). The value of a is 0.7. Above this range the Manning equation is applied with 
n = 1.0 and below this range there is no overland flow. 
<conveyance> 
<indexed file="man.index"> 
<entry id="1" label="typel"> 
<mannings a="1.000" detent="0.00001"> 
</mannings> 
</entry> 
<entry id="2" label="type2"> 
<lookup below ="10.0" above="30.0" base="1.0" expon="0.7"> 


<convey> 
0.0 04.0 
10.0 100.0 
20.0 400.0 
30.0 500.0 
</convey> 
</lookup> 
</entry> 
</indexed> 
</conveyance> 


3.4.1.4 Mixing Overland Flow Types 


Overland flow computations may involve different land use types in adjacent cells requiring 
different conveyance functions. When this happens the overland flow water mover needs the 
average conveyance between the cells, or something even more complex than simple averag- 
ing. Simple averaging or central differencing has its limitations under certain flow conditions, 
and can create oscillations at large gradients. Pure upwinding may be too diffusive. Consid- 
ering this, a number of options are available for conveyance computations based on upwind 
or central methods. These options are described in Table 3.12. An example demonstrating 
this option is shown below. 
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Table 3.12: Overland flow options for the ”compute” attribute under <conveyance>. 





Value of ” compute” | Definition 





mixed When using the compute="mixed" option, properties 
of overland flow depths and parameters are averaged to 
compute average properties which are used in comput- 
ing the conveyance. This option can be used only when 
Manning’s type conveyance is used. An average can be 
determined only if both cells have the same type. 





sep-central Under this option, the two cells can have two different 
conveyance functions which will be linearly averaged to 
compute the water mover conveyance. 





sep-upwind-par This partial upwinding assumes upwind method when 
the upwind conveyance is less that the downwind, and 
average otherwise. This helps to make sure that upwind- 
ing is used when really necessary. 





sep-upwind This is the complete upwind method applied whether the 
conveyance types are the same or different. 














<conveyance compute = "sep-upwind-par"> 
<indexed file="lu.index"> 
<entry id="1"> 
<mannings a="1.000" detent="0.00001"></mannings> 
</entry> 
</indexed> 
</conveyance> 


3.4.2 Groundwater Flow <transmissivity> 


Nine different methods are available to enter the transmissivity (or hydraulic conductivity) 

of confined and unconfined aquifers, as shown in Table 3.13. Seven methods are available 

directly under the <transmissivity> element including <indexed>, <confined>, 
<layered>, <lookuptr>, <unconfined>, <unconfined_gms>, and <unconfined_gms_layer>. 
Under the <indexed> and <entry> pathway, three more options are available includ- 

ing <confined_gms>, <confined_gms_layer>, and <layered_gms_layer>. Some 

of these options have been developed to facilitate the 3D groundwater flow analysis, which is 

described in Appendix C. Input options for all available methods of specifying transmissivity 

are defined in this section. 





For groundwater flow, transmissivity may be simply computed from a single hydraulic 
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Table 3.13: Allowable options under <transmissivity>. 
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Element 


Definition 


Reference Table 





<confined> 


Specifies the transmissivity of a 
confined aquifer 


Table 3.14 





<unconfined> 


Specifies the hydraulic conductivity 
of an unconfined aquifer 


Table 3.15 





<confined_gms> 


Specifies the transmissivity of a 
confined aquifer using a gms style 
file 


Table 3.16 





<unconfined_gms> 


Specifies the hydraulic conductiv- 
ity of an unconfined aquifer using 
a gms style file 


Table 3.17 





<confined_gms_layer> 


Specifies the transmissivity of a 3D 
confined aquifer using a gms style 
file 


Table 3.18 





<unconfined_gms_layer 


Specifies the hydraulic conductivity 
of a 3D unconfined aquifer using a 
gms style file 


Table 3.19 





<layered> 


Specifies the hydraulic conductivity 
of a 3D unconfined aquifer 


Table 3.20 








<layered_gms_layer> 


Specifies the transmissivity of a 3D 
confined aquifer using a gms style 
file 


Table 3.21 








<lookuptr> 





Specifies the transmissivity as a 
function of head 





Table 3.22 
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conductivity 
Q = LkdS (3.9) 


where 

L = width of the aquifer, 

d = the aquifer thickness, 

k = average hydraulic conductivity, and 

S = head gradient (i.e., hydraulic gradient) in the direction of flow. 


When the aquifer is layered, a lookup table (see Table 3.22) can be used to obtain the 
transmissivity of the aquifer at different heads. This has the advantage that all the informa- 
tion about the horizontal stratigraphy can be captured into one equation. The groundwater 
discharge is computed as 


Q = LK(H)S (3.10) 


where 

Q = discharge, 

L = length of the wall, 

K(H) = lookup table function describing transmissivity as a function of head. 


Following is an example where mixed transmissivity types are used in a model with 
various regions specified with indices. Index 1 in the example is a transmissivity lookup table 
where the two columns show the elevation and the transmissivity. The conveyance read from 
the lookup table is used between elevations 490.0 and 510.0. For index 2, the transmissivity 
is the product of the depth of water in the aquifer and the hydraulic conductivity k = 0.04 
m/s. 

<transmissivity> 

<indexed file="tran.index"> 

<entry id="1" label="typel"> 
<lookuptr below ="490.0" above="510.0"> 

<transm> 
0.0 0 
100.0 10. 
5 
0 





400.0 
600.0 20. 
</transm> 
</lookuptr> 
</entry> 
<entry id="2" label="type2"> 
<unconfined k=".04"> 
</unconfined> 
</entry> 
</indexed> 
</transmissivity> 


O O O O 
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The <lookuptr> example is also demonstrated in benchmark 36. 
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Table 3.14: Definition of variables for <confined> under <transmissivity>. 


















































<Element> or | Definition Dimensions| Variable Suggested Default | Example 
Attribute type range 
<confined> Specifies the transmissivity of a confined aquifer. 
trans The transmissivity of a confined | L?T~! Real > 0.0 Req 0.04 
aquifer 
NA = Not Applicable; Req. = Required. 
Table 3.15: Definition of variables for <unconfined> under <transmissivity>. 
<Element> or | Definition Dimensions | Variable Suggested Default | Example 
Attribute type range 
<unconfined> | Specifies the hydraulic conductivity of a unconfined aquifer. 
k The hydraulic conductivity of | L?T~! Real > 0.0 Req 0.004 








the unconfined aquifer 




















NA = Not Applicable; Req. = Required. 
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Table 3.16: Definition of variables for <confined_gms> under <transmissivity>. 















































<Element> or At- | Definition Dimen- | Variable Suggested | Default | Example 
tribute sions type range 
<confined_gms> Specifies the transmissivity of a confined aquifer using a gms style. 
file The name of the gms file contain- | NA String Any valid tr.gms 
ing confined transmissivities GMS file 
name 
mult Multiplier converting transmis- | NA Real Any valid | 1.0 0.3048 
sivity units real 
NA = Not Applicable; Req. = Required. 
Table 3.17: Definition of variables for <unconfined_gms> under <transmissivity>. 
<Element> or At- | Definition Dimen- | Variable Suggested | Default | Example 
tribute sions type range 





<unconfined_gms> 


Specifies the hydraulic conductivi 


ty of an unconfined aquifer using a 


gms style file. 


























file The name of the gms file contain- | NA String Any valid tr.gms 
ing unconfined K’s GMS file 
name 
mult Multiplier converting hydraulic | NA Real Any valid | 1.0 0.3048 
conductivity units real 








NA = Not Applicable; 


Req. = Required. 
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Table 3.18: Definition of variables for <confined_gms_layer> under <transmissivity>. For 8D flow analysis (see 
Appendix C) 
<Element> or At- | Definition Dimen- | Variable Suggested | Default | Example 
tribute sions type range 
SCONE ined_gms_layery Specifies the transmissivity of a confined aquifer using a gms style file. 
file The name of the gms file contain- | NA String Any valid | Req. tr.gms 
ing confined transmissivities GMS file 
name 
mult Multiplier converting transmis- | NA Real Any valid | 1.0 0.3048 
sivity units real 
layer Layer number NA Integer | Any valid | Req. 2 
layer num- 
ber 























NA = Not Applicable; Req. = Required. 











LAdNI TWX UNV SINANOdWOO TAHCOW HSH ‘€ YHLIdVHO 


v9 


Table 3.19: Definition of variables for <unconfined_gms_layer> under <transmissivity>. For 3D flow analysis (see 


Appendix C) 














<Element> or Attribute | Definition Dimen- Variable Suggested | Default Example 
sions | type range 

<unconfined_gms_1l ayer) Specifies the hydraulic conductivity of an unconfined aquifer using a gms style file. 

file The name of the gms file contain- | NA String Any valid | Req. tr.gms 
ing unconfined K’s GMS file 

name 

mult Multiplier converting hydraulic | NA Real Any valid | 1.0 0.3048 

conductivity units real 


























NA = Not Applicable; Req. = Required. 








Table 3.20: Definition of variables for <layered> under <transmissivity>. For 3D flow analysis (see Appendix C) 





<Element> 
or Attribute 


Definition 


Dimensions 


Variable 
type 


Suggested 
range 


Default | Example 





<lewerecs 


Specifies the hydraulic conductivity 


of a layered aquifer. 





cond 








The hydraulic conductivity of a 


layer 


ee 








Real 





> 0.0 Req. 0. 








004 
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Table 3.21: Definition of variables for <layered_gms_layer> under <i 


transmissivity>. For 3D flow analysis (see Ap- 






















































































pendix C) 
<Element> or | Definition Dimen- Variable) Suggested | Default| Example 
Attribute sions | type range 
Klayered.oms layer) Specifies the transmissivity of a layered aquifer using a gms style file. 
file The name of the gms file containing | NA String Any valid | Req. tr.gms 
transmissivities per layer GMS file 
name 
mult Multiplier converting transmissivi- | NA Real Any valid | 1.0 0.3048 
ties units real 
layer Layer number NA Integer | Any valid | Req. 2 
layer num- 
ber 
Table 3.22: Definition of variables for <lookuptr> under <transmissivity>. 
<Element> Definition Dimensions | Variable | Suggested | Default | Example 
or Attribute type range 
<lookuptr> | Denotes a lookup table of transmissivity as a function of head. 
below The elevation of the lower | L Real > 0.0 0 490.0 
end of the lookup table 
above The elevation of the upper | L Real > 0.0 0 520.0 
end of the lookup table 
flstat Not available in current | NA String yorn n y 
version 
<transm> A 1D lookup table of depth and transmissivity 
NA = Not Applicable; Req. = Required 
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3.5 Water Movers 


3.5.1 Introduction to Water Movers 


Movement of water between water bodies in the HSE can take place only through water 
movers. Water mover objects contain functions to compute the flow of water from one water 
body to another. 


Water movers fall into three general categories. 


1. Default water movers are automatically created when the mesh and canal network 
are set up. Overland flow and groundwater flow water movers between adjacent cells 
in the mesh, and canal flow between adjacent canal segments are examples of default 
water movers that are created automatically based on the 2-D mesh or canal network 
geometry files. 


2. Concept water movers in which water flow is computed using generic equations 
that can be used to represent actual structures in a limited way. Lookup tables, time 
series, and power functions are examples of concept water movers. These are intended 
to provide flexibility for the user to represent movement of water with methods that 
are not included in the other categories. 


3. Physical structure water movers are designed to represent man-made structures 
such as weirs, culverts, and orifices. 


Water movers are cumulative by design. Addition of a water mover will not replace 
an existing water mover including the default overland flow, groundwater flow, and canal 
flow water movers. An unlimited number of water movers can be implemented between any 
two water bodies. As a result, when a concept or structure water mover is added between 
two water bodies, it does not replace any of the existing water movers, but merely adds to 
them. To prevent unintended flow from a default water mover between water bodies when 
a structure is added, a no-flow boundary condition for default water movers must be placed 
at the location of the structure. Examples where this is appropriate are a weir that controls 
flow in a canal so that all the water passes through the weir or a road that blocks flow so 
that all the flow between cells on opposite sides of the road occurs through culverts under 
the road. The water mover that replaces the default water mover is created by the user. Any 
number of water movers may be used to simulate flow between water bodies. If the default 
water mover is not removed, both the water mover and the user created water mover(s) are 
implemented. An example of XML input for a junction block that eliminates the default 
water mover between canal segments 23 and 34 is shown below. 


This section primarily describes the user-defined water movers. Most of the water movers 
described here such as culverts and weirs are designed to move water between adjacent water 
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bodies, but several may reasonably be used to move water from any water body to any other 
water body whether they are adjacent or not. The user must decide the most appropriate 
water mover for the physical situation being simulated. Some water movers can be user- 
defined to prevent reverse flow or flow against gravity. 


The following XML input will block flow by the default water mover between canal segments 
23 and 34. 


<network_bc> 
<junctionblock idl="23" id2="34"> </junctionblock> 
</network_bc> 


In the case of a road separating two cells, overland flow will be prevented by the following 
instructions. Water movers for walls defined by nodes 2-4 and 4-67 will be removed. 


<mesh_bc> 
<noflow section="ol"> 
<nodelist> 2 4 67 </nodelist> 
</noflow> 


aaeh BSS 
Groundwater flow can be prevented through the same walls by replacing ”ol” with ” gw”. 


Water movers may also be assigned water mover identification numbers that can be used 
later in specifying water budget output. 


3.5.2 Default Water Movers 


No XML input is needed to define the default water movers. These are automatically gen- 
erated by HSE after the 2D grid is input to the model and after the 1D canal network is 
built. 


3.5.3 Concept Water Movers 


Concept water movers are versatile, but they must be used carefully because they are very 
general and are intended to give the user flexibility when the flow characteristics are known, 
although they are not designed to represent any predefined structure. For example, the 
general power law water mover may represent a rectangular weir, but may not consider 
the effects of downstream submergence or end contractions. Table 3.23 lists some available 
concepts for water movers. 
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Table 3.23: List of concept water movers. 





Element Description 





<delta_control> | A 1-D lookup table type function of discharge against 
water head difference 





<doublet> A source and a sink couple 








<setflow> Controllable user-defined flow 





“oud |. contro L> A 2-D lookup table type function with discharge read 
against upstream and downstream head values. 











<genweir> A general weir equation applicable for many weir types 
<hq_relation> A simple head - discharge relationship 
<shunt> A short circuit between water bodies 





<single_control> | A lookup table between head and discharge 








<source> A pure source or a sink 














<standardweir> A common weir type 





3.5.3.1 Simple Power Law Based Water Mover <st andardweir> 


The standard weir water mover is created by the <standardweir> element. Discharge 
from water body 1 to water body 2 through a standard weir is expressed as 


Qi = CL(H, = z)’ (3.11) 


where 

C = weir coefficient, 

H,= water level in water body 1, 
z = weir crest elevation, and 

b = user specified exponent. 


A complete specification of the attributes of a standard weir are defined in Table 3.24. 


Table 3.24: Attribute definitions for <standardweir>. 















































Attribute Definition Dimensions | Variable Suggested Default Example 
type range 
id1 ID of the upstream water | NA Integer | 200000-300000 | Req 256987 
body 
id2 ID of the downstream water | NA Integer | 200000-300000 | Req 268546 
body 
wmID ID of the water mover NA Integer | 500000-600000 | -1 568546 
fcoeff Weir coefficient for flow | LT~! Real > 0.0 Req 0.53 
in the forward direction 
NOTE: <bcoeff> is 
used for both forward 
and reverse flow 
bcoeff Weir coefficient for flow | LT! Real > 0.0 Req. 0.53 
in the reverse direction 
NOTE: <bcoeff> is 
used for both forward 
and reverse flow 
length Crest length (L) L Real > 0.0 Req 85.6 
crestelev | Crest elevation (z) of the weir | L Real > 0.0 Req 26.3 
power The exponent (b) in the weir | NA Real > 0.0 Req. 0.6 
equation 
label An optional label for the weir | NA String Any string wm+wmlID| Miami weir 


























NA = Not Applicable; Req = Required. 
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The following example describes a <standardweir> water mover connecting water body 
2 to water body 7. 


<watermovers> 
<standardweir 

idl = "2" id2 = "7" wmID = "201" 

fcoeff = "0.2" bcoeff = "0.1" length = "20.0" crestelev = "501.0" 


power = "2.3"> 
</standardweir> 


</watermovers> 


3.5.3.2 General Power Law Based Water Mover <genweir> 


The <genweir> water mover uses a power equation of the form 


Qiz = CL(H, — z)*( Hy — H3)’ (3.12) 


where C = user specified weir coefficient, 

A, and H= water levels in water bodies 1 and 2, 
z = weir crest elevation, 

a = user specified coefficient, and 

b = user specified exponent. 


Because of the flexibility of the <genweir> water mover, the user may decide to use 
this equation for certain types of weirs or bridges. For example, flow through a V-notch weir 
is calculated as 


Q= Šk 2g tan(0/2)(H — Z)?* (3.13) 


and may be simulated by assigning appropriate values of the variables. Complete specifica- 
tion of the attributes of a general power law based water mover are defined in Table 3.25. 


The following example describes a <genweir> water mover connecting water body 5 to 
water body 11. 


<watermovers> 
<genweir idl = "5" id2 = "11" fcoeff = "1.0" bcoeff="0.0" 
crestelev = "500.5" crestlen = "100" dpower = "1.5" spower = "0.5" > 
</genweir> 


</watermovers> 


Table 3.25: Attribute definitions for <genweir>. 












































Attribute Definition Dimensions | Variable Suggested Default | Example 
type range 

idl ID of the upstream wa- | NA Integer 200000-300000 Req. 256987 
ter body 

id2 ID of the upstream wa- | NA Integer 200000-300000 Req 268546 
ter body 

wmID ID of the water mover NA Integer 500000-600000 -1 568546 

fcoeff Weir coefficient used for | NA Real > 0.0 Req 0.38 
forward (1—2) flow. 

bcoeff Weir coefficient used for | NA Real > 0.0 Req 0.46 
reverse (2—1) flow 

crestelev | Crest elevation of the | L Real > 0.0 Req 23.8 
weir 

crestlen Weir crest length L Real > 0.0 Req 58.3 

dpower Exponent a for up- | NA Real > 0.0 Req 1.4 
stream depth over the 
weir 

spower Exponent 6 for water | NA Real => 0.0 Req 0.56 





level difference 























NA = Not Applicable; Req. = Required. 
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3.5.3.3 Coupled Source Sink Water Mover <doublet> 


The <doublet> water mover is a coupled source and a sink of equal magnitudes. Water 
may be removed from any water body and discharged into any other as could be done by 
pumping. Internally, this is treated the same as a boundary condition. The water is removed 
from one water body and put into a boundary condition reservoir. The same amount of wa- 
ter is removed from the boundary condition reservoir and discharged into the second water 
body. This is applied if a constant or time series discharge from one water body to another 
is to be implemented. A complete specification of the attributes of a doublet water mover 
are defined in Table 3.26 


The following sample XML input implements a constant flow from water body 5 to water 
body 11 and a time series of flows in DSS format from water body 6 to waterbody 31. 





<watermovers> 

<doublet idl = "5" id2 = "11" label = "whatever"> 
<const value = "-100.5" dbintl = "300"> </const> 

</doublet> 

<doublet idl = "6" id2 = "31" label = "S-205"> 
<dss file ="S-201/dss" pn="/hse/t3x3 P02/FLOW //300min/CALC/"> 
</dss> 

</doublet> 


</watermovers> 


Table 3.26: Attribute definitions for <doublet>. 
























































Attribute Definition Dimensions| Variable | Suggested Default Example 
type range 

idi ID of the upstream wa- | NA Integer 200000-300000 | Req. 256987 
ter body 

id2 ID of the upstream wa- | NA Integer 200000-300000 | Req. 268546 
ter body 

wmID ID of the water mover NA Integer 500000-600000 | Req. 568546 

label An optional label for the | NA String Any string wm+wmID | Pump 416 
doublet 

<const> A constant flow rate will be specified 

LTES A flow rate defined by a rule curve is provided. 

<dss> A time series in DSS format is provided. 





Details on specifying input data in <const>, <rc>, and <dss> formats are provided in chapter 6 








NA = Not Applicable; Req. = Required. 
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3.5.3.4 Controllable User-Defined Flow <set flow> 


The setflow watermover <set flow> is identical to the doublet watermover except that a 
controller as described in the MSE manual may be applied. It applies a user-defined constant 
flow or time series flow from one waterbody to another. 


Complete specifications of the attributes of a <setflow> water mover are defined in 


Table 3.27 The 


following XML implements a controllable constant flow from water body 16 


to water body 32 through water mover and a controllable time series of flow from water body 
64 to water body 128 through water mover 124. 


<watermov 


<setfl 
<con 





</watermo 


ers> 
ow wmID="123" idl = "16" id2 = "32" label = "transfer"> 
st value = "64" dbintl = "15"> </const> 
flow> 
low wmID='’'124''’ idl = "64" id2 = "128" label = "transfer"> 
file ="S-201/dss" pn="/hse/t3x3 P02/FLOW //300min/CALC/"> </dss> 
flow> 





vers> 


Table 3.27: Attribute definitions for <setflow>. 
























































Attribute Definition Dimensions| Variable | Suggested Default Example 
type range 

<id1> ID of the upstream water | NA Integer 200000-300000 | Req. 256987 
body 

<id2> ID of the upstream water | NA Integer 200000-300000 | Req. 268546 
body 

<wmID> ID of the water mover NA Integer 500000-600000 | Req. 568546 

label An optional label for the | NA String Any string wm+wmID | Drain 345 
water mover 

<const> A constant flow rate will be specified 

LTES A flow rate defined by a rule curve is provided. 

<dss> A time series in DSS format is provided. 





Details on specifying input data in <const>, <rc>, and <dss> formats are provided in chapter 6 








NA = Not Applicable; Req. = Required. 
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3.5.3.5 Lookup Table Based Water Movers 


Three water movers are lookup table types that are useful if the discharge from one wa- 
ter to another depends on the value of the head or heads in one or more water bodies. 
The lookup table types that can be used are <single_control>, <dual_control>and 
<delta_control> as described below. 


3.5.3.6 Single Control Water Movers <single_control> 


The <single_control> water mover uses a 1-D lookup table to determine the discharge 
from any water body to any other water body. The flow, Q, is determined from a user 
specified one dimensional rating curve or lookup table with the head in any specified water 
body being the independent variable. The first column of the table is the value of the 
independent variable and the second column is the corresponding discharge. The upstream 
head is the most commonly used control point although the head in any water body may be 
used. Complete specifications of the attributes of a <singlecontrol> water mover are 
defined in Table 3.28 


Table 3.28: Attribute definitions for the <single_control> Water Mover. 



































Attribute Definition Dimen- | Variable Suggested Default Example 
sions type range 

idl ID of the upstream water | NA Integer 200000-300000 | Req. 256987 
body 

id2 ID of the upstream water | NA Integer 200000-300000 | Req 268546 
body 

wmID Water Mover ID NA Integer 200000-300000 | -1 268546 

control ID of the control water | NA Integer 200000-300000 | Req. 568546 
body. 

cutoff Head in the control water | L Real > 0.0 Req 15.36 
body below which no flow 
Occurs. 

gravflow Specifies whether only | NA String ” yes” or ”no” Req. ? yeg” 
gravity flow can oc- 
cur (flow can occur 
only from upstream to 
downstream). 

revflow ” yes” allows reverse flow | NA String ” yes” or ”no” Req. ” yeg” 

label Optional label for the wa- | NA String Any String wm+wmID | "Irrigation 
ter mover. Pump” 


























NA = Not Applicable; Req. = Required. 
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An example of <single_control1> is shown below. The example shows how a single con- 
trol water mover can be used to trigger the operation of a pump as the water level at water 
body 10034 reaches 5.8-5.9 m. The flow is from a pump that has the pumping characteristics 
shown in the lookup table. The pump starts pumping when the head in water body 10034 
reaches 5.0 m and reaches a maximum pumping rate of 31.545 m3/sec at a head of 6.1 m. 


<watermovers> 


<single_control id1l="10034" id2="354" wmID = "35" control="10034" cutoff="3. 


gravflow = "no" revflow = "yes" label="Pump at the impoundment" > 
<0 0.0 


aon w | 


6; 
30.0 31.545 
</single_control > 
</watermovers> 


3.5.3.7 Dual Control Water Movers <dual_control> 


The <dual_control> water mover uses a 2D lookup table to determine the discharge from 
any water body to any other water body. The flow, Q, is determined from a user specified 
two-dimensional rating curve or lookup table with the heads in the specified water bodies 
being the independent variables. The first column of the table is the value of the head in 
the first water body, the first row is the head in the second water body and the remaining 
rows and columns are the corresponding discharges. The discharges for intermediate heads is 
determined by 4-point linear interpolation. The water bodies need not be adjacent although 
they often will be. 


The attributes of a <dual_control> water mover are explained in Table 3.29 


o" 


Table 3.29: Attribute definitions for the <dual_control> Water Mover. 



































Attribute Definition Dimen- | Variable Suggested Default Example 
sions type range 

idl ID of the upstream water | NA Integer 200000-300000 | Req 256987 
body 

id2 ID of the upstream water NA Integer 200000-300000 | Req 268546 
body 

wmID Water Mover ID NA Integer 200000-300000 | -1 268546 

control ID of the control water NA Integer 200000-300000 | Req 568546 
body (Not Implemented) 

cutoff Head in the upstream wa- | L Real > 0.0 Req. 15.36 
ter body below which no 
flow occurs. 

gravflow Specifies whether only | NA String ” yes” or “no” Req. ” yes” 
gravity flow can occur 
(flow can occur only from 
upstream to downstream). 

revflow ” yeg” allows reverse flow NA String ” yes” or ”no” Req. ? yeg” 

label Optional label for the wa- | NA String Any String wm+wmID | ” Weir 
ter mover. 1A” 


























NA = Not Applicable; Req. = Required. 
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An example of the input for a <dual_control> water mover is shown below. In the 
example, cell 5 is the upstream water body, and segment 21 is the downstream water body. 
Columns 2-4 represent various watermover flow values corresponding to the downstream 
head specified in row 1 (segment 21), and the upstream head of column 1 (cell 5). Only 
gravity flow can occur and reverse flow is not allowed. 


<watermovers> 
<dual_control idl="5" id2="21" cutoff = "1.0" gravflow = "yes" 
revflow = "no" label="Flooding Overflow"> 





495 500 505 510 
495.0 0 1000 2000 3000 


500.0 0 0 1500 2500 
505.0 0 0 0 2000 
510.0 0 0 0 0 
</dual_control> 
</watermovers> 


3.5.3.8 Delta Control Water Movers <delta_control> 


The <delta_control> water mover uses a 1-D lookup table to determine the discharge 
from any water body to any other water body. The flow, Q, is determined from a user 
specified one dimensional rating curve or lookup table with the independent variable being 
the difference between the upstream head and the downstream head. The first column of the 
table is the value of the independent variable and the second column is the corresponding 
discharge. 


The attributes of a <delta_control> water mover are explained in Table 3.30 


Table 3.30: Attribute definitions for the <delta_control> Water Mover. 




















Attribute Definition Dimensions Variable | Suggested Default Example 
type range 
idl ID of the upstream water | NA Integer 200000-300000 | Req. 256987 
body 
id2 ID of the upstream water | NA Integer 200000-300000 | Req. 268546 
body 
wmlD Water Mover ID NA Integer 200000-300000 | -1 268546 
label Optional label for the wa- | NA String Any String wm+wmlD | ”Flood 
ter mover. Control 
Pump” 


























NA = Not Applicable; Req = Required. 
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Flow through a delta control structure is from water body id1 to id2 if the head differ- 
ence H_1 - H_2 is positive and from id2 to id1 if it is negative. An example of input for a 
delta control lookup table is shown below. Flow is in either direction between water body 5 
and water body 15. The flow increases rapidly as the head difference increases from 4 to 6 
meters. 


<watermovers> 
<delta_control idl="5" id2 ="15" label="t3x3-2"> 
4.0 0 
5:20:10 
6.0 10000 
</delta_control> 
</watermovers> 


3.5.3.9 Comments On The Use Of Lookup Tables 


Since a large variety of flow discharge relationships can be described using lookup tables, 
it is important to follow a number of simple rules to prevent the model from generating 
erroneous results. 


1. It is not necessary to provide smooth stage-discharge relationships. However, smooth 
relationships give more accurate results because the slope estimates of the curve become 
more accurate when the flow relationship is linearized. 


2. When water levels encountered are outside the bounds described in the lookup table, 
linear extrapolation is used to compute discharge. However, to prevent the discharges 
becoming excessively large or small during extrapolation, it is recommended that the 
user define a rating curve over a broad range of heads to prevent unrealistic flows being 
imposed. 


3. A 1-D lookup table needs a minimum of two points and a two-dimensional lookup table 
needs a minimum of four points. 


3.5.3.10 Shunt Watermover <shunt> 


The shunt water mover, <shunt>, is used when two water bodies are connected, and there 
is no obvious choice except for a shunt. A shunt can be used if a canal ends up in a reservoir 
with no structure to separate them. The flow, Q, is 


Qi = K(Hı — H2) (3.14) 
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where K is a user specified constant and Hı and Hə are the heads in the two water bodies. 
Complete specifications of the attributes of a <shunt> water mover are defined in Table 3.31. 


Table 3.31: Attribute definitions for a shunt Water Mover. 


























Attribute Definition Dimen- | Variable | Suggested Default | Example 
sions type range 

idl ID of the upstream water | NA Integer 200000-300000 | Req 256987 
body 

id2 ID of the downstream wa- | NA Integer 200000-300000 | Req 268546 
ter body 

wmID Water Mover ID NA Integer 200000-300000 | -1 24956 

sconst Conveyance of the shunt | L?T7! Real >0.0 Req. 4.7 
(K in the flow equation) 

bottom Head in water body 1 be- | NA Real > 0.0 Req 11.64 





low which no flow occurs. 























NA = Not Applicable; Req = Required. 
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The XML input below creates a water mover with ID 9 that moves water between water 
bodies 10134 and 20001 according to the shunt equation. Flow may occur in either direction. 


<watermovers> ... 

<shunt wmID = "9" idl = "10134" id2 = "20001" 
sconst = "0.1" bottom = "128.2"> </shunt> 
</watermovers> 


3.5.4 New And Borrowed Physical Structure Types 


A number of water movers have been included in the code to provide flexibility for modelers 
although the approaches and algorithms for some have not been extensively tested and 
verified by OoM staff. Only some of these water movers will be used in the SFWMD 
implementation of the RSM to South Florida (SFRSM), although they are supported for 
other implementations. Water movers that will not be used in the SFRSM and have not been 
thoroughly tested by the OoM will be identified in the description of each and the modeler 
is advised to use them only with a clear understanding of the underlying algorithms. It is 
the modelers responsibility to ensure that an algorithm is suitable for use in a particular 
application. 


Several structure types have been added from other models such as the Multi Basin 
Routing Model (MBR) that has evolved into the CASCADE model. Others structure types 
were added to the HSE model by coding algorithms for equations that were published in 
model users manuals and technical guidance documents. These structures can be applied 
between any two water bodies. Downstream submergence conditions are considered for some 
of these structures. When a structure is added, a no-flow condition has to be applied for the 
specific wall if the water bodies are adjacent (the normal case). These water movers and the 
sources of the algorithms used to compute flow are listed in Table 3.32. 


3.5.5 Culvert Water Mover <culvert> 


This water mover has not been thoroughly tested or verified by the SFWMD Office of 
Modeling (OoM). 


The culvert water mover was borrowed from the National Weather Service. While it was 
written for the FLDWAV model it was never thoroughly tested and was not incorporated 
into the FLDWAV manual (Danny Fread, Ming Jin, Personal Communication). Figure 3.4 
shows a definition sketch of a circular culvert. It uses six different flow types as is commonly 
done for culvert analysis. These are listed below along with the equations to compute flow. 
Table 3.33 shows the attributes of a culvert. 
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Table 3.32: List of physical water movers. 
































Element Description 

<culvert> Culvert water mover borrowed from the National 
Weather Service (NWS). 

<gateweir> Gated weir borrowed from the NWS FLDWAV manual 

<spill> Spillway water mover borrowed from the NWM FLD- 
WAV Manual 

<pipe> Pipe water mover borrowed from MBR 

<mbrbroadweir> Broad crested weir borrowed from MBR 

<mbrsharpweir> Sharp crested weir borrowed from MBR 

<mbrdropweir> Drop weir borrowed from MBR 

<yarnell> Bridge routine based on Yarnell equations derived from 
the HECRAS Technical Reference Manual 

<vnotchbleeder> V-notch bleeder borrowed from MBR 





<circularbleeder> 





Circular bleeder borrowed from MBR 








<rectbleeder> 





Rectangular bleeder borrowed from MBR 








<hydropower> 





Hydropower plants - from general properties of hy- 
dropower. 
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1. If the outlet is submerged, discharge is computed in English units as 





29(¥1 — Y2) 
g= ca, 14 BIEL (3-1) 
R4/3 





where 

C = a user specified discharge coefficient, 
A = cross sectional area of the culvert, 
R = hydraulic radius, 

Y1 = upstream head, 

Y2 = downstream head, 

n = Manning’s roughness coefficient, 

L = culvert length, 

g = acceleration due to gravity. 


2. Upstream depth > 1.3 culvert diameter (or height for a rectangular culvert) and length 
<= 20«diameter, the culvert is hydraulically short and discharge is inlet controlled. 





Q =0.7CAy/2g(H1 — 0.6D) (3.16) 


A = cross sectional area of the culvert 
H1 = upstream depth 
D = culvert diameter (height for a rectangular culvert). 


3. Upstream depth > 1.3 culvert diameter (or height for a rectangular culvert) and length 
> 20xdiameter, the culvert is hydraulically long and discharge is outlet controlled. 





2g(Y1 — maz(Y 2, CH2 + 0.5D 
Q= orca at ; E ) (3.17) 
+ pays 





where CH2 = culvert invert at the downstream end. 


4. If upstream depth < 1.3D and the culvert has a mild slope 





Q = CAy/2g * (Y1 — CH2) (3.18) 

where V1—CH2 
A=W (3.19) 

1.25 + 33 


for a rectangular culvert and 


A = [0.785Y — 0.045 sin(27Y)|D? (3.20) 
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for a circular culvert. 
W = width of a rectangular culvert 


Y = 
D 
~y tagh? 


DC = —— s 
Lt oe 


with DC = D if DC > D and D = diameter of a circular culvert. 


89 


(3.21) 


(3.22) 


5. If upstream depth < 1.3D and the culvert has a steep slope with the downstream water 


depth less than critical depth. 





Q = CAy/29 * (Y1 — CH1) 


where 


ESCH 


A Yi aH 
1.05 + @ 


for a rectangular culvert and 
A = [0.785Y — 0.045 sin(27Y)|D? 


for a circular culvert. 
In these equations, W = width of a rectangular culvert, 


_ DC 


Y 
D 


CH 


«1.05 + %7 


DC 





with DC = Dif DC > D. 


(3.23) 


(3.24) 


(3.25) 


(3.26) 


(3.27) 


6. If upstream depth < 1.3D and the culvert has a steep slope with the downstream water 


depth greater than or equal to critical depth. 





Q = CAy/2g * (Y1—Y2) 


where 


A=WH2 


for a rectangular culvert 


(3.28) 


(3.29) 
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A = [0.785Y — 0.045 sin(27Y)|D? 


for a circular culvert 


where W = width of a rectangular culvert and 


DC 
Y= 
DF 

DC =Y2- Y1 


and DC = D if DC > D. 
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(3.30) 


(3.31) 


(3.32) 


Table 3.33: Attributes of the <culvert> water mover. 









































Attribute Definition Dimensions | Variable | Suggested Default Example 
type range 

idl ID of the upstream water | NA Integer 100000-200000 | Req. 153675 
body 

id2 ID of the downstream water | NA Integer 100000-200000 | Req. 148322 
body 

wmid ID of the water mover being | NA Integer 200000-300000 | -1 256987 
created 

width Width of a box culvert. | L Real > 0.0 Req 2.5 
Set=0 for a circular culvert 

height Height of a box culvert or di- | L Real > 0.0 Req 4.25 
ameter of a circular culvert 

length Length of the culvert barrel | L Real > 0.0 Req. 110.6 

mann Manning’s roughness coeffi- | TL13 Real 0.0 — 0.2 Req. 0.024 
cient 

coeff Discharge coefficient for the | NA Real 0.39 — 0.98 Req. 0.42 
culvert 

hw_inv Elevation of the upstream | L Real > 0.0 Req. 13.86 
culvert invert 

tw_inv Elevation of the downstream | L Real > 0.0 Req 10.48 
culvert invert 

rev Specifies whether reverse | NA String N or Y Req. Y 
flow is allowed. N prevents 
reverse flow. Y is default. 

label Optional label for the water | NA String Any String wm+wmlD | Route 75 
mover. culvert 


























NA = Not Applicable; Req. = Required. 
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An example XML input for a circular culvert is shown below. A culvert labeled water 
mover 231 connects water body 5 with water body 21. Since ”width” = 0 this is a circular 
culvert with diameter 3.2 meters and a length of 40 meters. It is probably concrete (Man- 
ning’s n = 0.012) and the discharge coefficient is 0.4. The culvert is horizontal with the same 
invert at both ends. An overland flow block should be created between water bodies 5 and 
21 if the culvert carries all the flow. 


<watermovers> 

<culvert idl = "5" id2="21" wmID = "231" width = "0" height = "3.2" length = "40" 
mann = "0.012" coeff = "0.4" hw_inv = "0.91" tw_inv = "0.91" rev = "y" > 

</culvert> 

</watermovers> 


3.5.5.1 MBR Pipe Flow <pipe> 


The <pipe> water mover has not been extensively tested or verified by the OoM staff. It 
should be used by experienced users of the MBR or CASCADE model with a full under- 
standing of the algorithms used to compute flow. 


This feature borrowed from MBR is not as robust as <culvert>. Depending on various 
upstream and downstream conditions, this too uses six flow regimes. Figure 3.4 shows a 
definition sketch for pipe flow. Table 3.34 shows the XML attributes used to define the pipe 
water mover. 


Figure 3.4: Definition sketch of a pipe. 


Headwater a 


J Tailwater 
Invert= æ 


L ~ / Invert 












Y1 CH1 CH2 | 


Datum _ 





Table 3.34: Attributes used to define a <pipe> water mover. 









































Attribute Definition Dimensions| Variable | Suggested Default Example 
type range 

idi ID of the upstream water | NA Integer 100000-200000 | Req. 153675 
body 

id2 ID of the downstream water | NA Integer 100000-200000 | Req 148322 
body 

wmid ID of the water mover being | NA Integer 200000-300000 | -1 256987 
created 

diameter | Diameter of a circular pipe | L Real > 0.0 Req 4.25 

length Length of the pipe L Real > 0.0 Req. 110.6 

mann Manning’s roughness coeffi- | TL! Real 0.0 — 0.2 Req 0.024 
cient 

hw_inv Elevation of the upstream | L Real > 0.0 Req 13.86 
culvert invert 

tw_inv Elevation of the downstream | L Real > 0.0 Req. 10.48 
culvert invert 

rev Specifies whether reverse | NA String N or Y Req. Y 
flow is allowed. N prevents 
reverse flow. 

label Optional label for the water | NA String Any String wm+wmID | Highway 
mover. 66 culvert 


























NA = Not Applicable; Req. = Required. 








LAdNI TWX UNV SINANOdWOO TACOW HSH ‘€ YHLdVHO 


€6 


CHAPTER 3. HSE MODEL COMPONENTS AND XML INPUT 94 


Following is an example of a data set for a pipe. 


<watermovers> 
<pipe idl = "5" id2="21" diameter = "3.71" 
length = "212.0" mann = "0.012" 
hw_inv = "0.91" tw_inv = "0.91" rev = "Y"> 
</pipe> 
</watermovers> 


The pipe in this example connects the water body 5 to water body 21 with a pipe of 
diameter 3.71 m with reverse flow allowed. 


3.5.5.2 MBR Broad Weir <mbrbroadweir> 


The broad crested weir water mover equations have not been thoroughly tested and verified 
by OoM staff. The broad crested weir shown in Figure 3.5 is borrowed from the MBR model 
with discharge equation 


Q = CaL(H1 — z)” (3.33) 


The discharge is modified with a tailwater correction CS so that Q = Q * CS 


If TW > 0.99H then Q = 0 
If 0.95H < TW < 0.99H 


100(TW/H — 1) 





CS = 0.965 — exp( 1 — 0.43) (3.34) 
If 0.76H < TW < 0.95H 
100(TW/H — 1 
CS = 1.0 — exp( oa ) 0.2) (3.35) 





4 
Iw < 0768, CS = 1.0 


where, L = weir length; z = crest elevation, TW = H2 - z, and H = H1 - z. The value 
of C4 should be in the range 3.05-3.10. The attributes needed to define a broad crested weir 
water mover are explained in Table 3.35 
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Figure 3.5: Definition sketch of broad crested weir. 


The following example describes a broadcrested weir that moves water from water body 5 
to water body 21 with a discharge coefficient of 2.9. The weir length is 100 meters and the 
crest elevation = 5.2 meters. 


<watermovers> 
<mbrbroadweir idl = "5" id2="21" 

crestelev = "5.2" length = "100.0" coeff = "2.9"> 
</mbrbroadweir> 


</watermovers> 


Table 3.35: Attributes of a broad crested weir, <mbrbroadweir>. 
































Attribute Definition Dimensions| Variable | Suggested Default Example 
type range 

idl ID of the upstream water | NA Integer 100000-200000 | Req. 153675 
body 

id2 ID of the downstream water | NA Integer 100000-200000 | Req 148322 
body 

wmid ID of the water mover being | NA Integer 200000-300000 | -1 256987 
created 

crestelev Elevation of the weir crest L Real > 0.0 Req 14.78 

length Length of the weir across the | L Real > Req. 116.8 
channel 

coeff Discharge coefficient Ler Real cata Req. 0.48 

label Optional label for the water | NA String Any String wm+wmlD | Domino 
mover. Sugar 

weir 


























NA = Not Applicable; Req. = Required. 
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3.5.5.3 MBR Sharp Weir <mbrsharpweir> 


The sharp crested weir is also borrowed from the MBR model. Figure 3.6 shows a definition 


sketch of a sharp crested weir. 


Figure 3.6: Definition sketch of a sharp crested weir. 











st Elevation = Z—~—| I — 














Discharge is computed as 


Q =3.13(CS)L(H — z)"5 (3.36) 


where 

L = weir length, 

CS = Tailwater correction, 

H = Head over weir crest = H1 - z, 

z = Elevation of the weir crest, and 

C'S = 1.0 unless TW = H2 - z > 0 and then, 


TW \1.5)0.385 (3.37) 


s= i= 


according to (Brater et al., 1996). 
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The following example creates a sharp crested weir that carries water from water body 7 to 
water body 20. 


<watermovers> 

<mbrsharp idl = "7" id2="20" 
crestelev = "2.3" length = "80.0"> 

</mbrsharp> 


</watermovers> 


Table 3.36: Attributes of a sharp crested weir, <mbrsharpweir>. 





























Attribute Definition Dimensions| Variable | Suggested Default Example 
type range 

idl ID of the upstream water | NA Integer 100000-200000 | Req 153675 
body 

id2 ID of the downstream water | NA Integer 100000-200000 | Req. 148322 
body 

wmID ID of the water mover being | NA Integer 200000-300000 | -1 256987 
created 

crestelev Elevation of the weir crest L Real > 0.0 Req 12.93 

length Length of the weir across the | L Real > Req 63.7 
channel 

label Optional label for the water | NA String Any String wm+wmlD | Jones 
mover. Farm 

weir 


























NA = Not Applicable; Req. = Required. 
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3.5.5.4 MBR Drop Weir <mbrdropweir> 


The drop weir (Figure 3.7)is taken from the United States Bureau of Reclamation (Bureau 
of Reclamation, 1977). The physical structure is a ”morning glory” spillway. A vertical 
pipe with water flowing over the lip. In this model, it is assumed that the control is at the 
entrance to the pipe and that free flow exists below the entrance. Discharge is computed as 


Q =CLH'* (3.38) 


where C depends on the ratio of Head to pipe diameter. 


H 
R=2 3.39 
D (3.39) 
EFER>2,C=1 
If R < 0.3, C =4. 
Otherwise 
C = 4.01 + 0.72R —6.12R? + 4.37 R? — 0.93 Rt (3.40) 


The equation for computing C was obtained by fitting data from a nomograph in the USBR 
publication ” Design of Small Dams” with a fourth order polynomial. 


In the following example water spills from water body 7 into a vertical circular pipe of 


diameter 4.0 meters and top at elevation 2.3 meters, and is discharged to water body 20. 


<watermovers> 

<mbrdropweir idl SE 1A2=M20" 
crestelev = "2.3" length = "4.0"> 

</mbrdropweir> 


</watermovers> 
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Figure 3.7: Definition sketch of a drop weir. 
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Table 3.37: Attributes of a <mbrdropweir>. 





























Attribute | Definition Dimensions| Variable | Suggested Default Example 
type range 

idl ID of the upstream water | NA Integer 100000-200000 | Req 153675 
body 

id2 ID of the downstream water | NA Integer 100000-200000 | Req. 148322 
body 

wmid ID of the water mover being | NA Integer 200000-300000 | -1 256987 
created 

crestelev Elevation of the weir crest L Real > 0.0 Req 23.6 

length Length of the weir (Circum- | L Real > Req 76.3 
ference of the pipe) 

label Optional label for the water | NA String Any String wm+wmID | Detent 
mover. Pond 

Outlet 


























NA = Not Applicable; Req. = Required. 
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3.5.5.5 NWS Uncontrolled Spill <spil1> 


This is a spillway routine borrowed from the NWS FLDWAV model (Figure 3.8). Only 
downstream flow is allowed. Discharge is computed as 


Q = CS * CTW * Lx \/2g* H™ (3.41) 


where 

CS is a user specified coefficient, CTW is a tailwater correction, 
H = H1 - Crest Elevation, 

TW = H2 - Crest Elevation, 

CTW = 1.0 unless TW/H > 0.67. Then 


T 
CTW = 27.8 — 0.67)° (3.42) 


Attributes of the uncontrolled spillway are listed in Table 3.38 





i 
H 










Crest Elevation 


H2 








Figure 3.8: Definition sketch of an uncontrolled spillway. 
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In the following example water flows from water body 2381 over a spillway to water body 
4216. The crest elevation is 23.6 meters and the length of the spillway is 76.3 meters. 


<watermovers> 
<spill idl = "2381" id2="4216" 

crest = "23.6" width = "76.3" c15="0.42"> 
</spill> 


</watermovers> 


Table 3.38: Attributes of an uncontrolled spillway <spill>. 





























Attribute | Definition Dimensions| Variable | Suggested Default Example 
type range 

id1 ID of the upstream water body | NA Integer 100000-200000 | Req. 153675 

id2 ID of the downstream water | NA Integer 100000-200000 | Req. 148322 
body 

wmid ID of the water mover being | NA Integer 200000-300000 | Req. 256987 
created 

c15 Discharge coefficient NA Real 0.35 to 0.45 Req. 0.42 

crest Elevation of the weir crest L Real > 0.0 Req. 16.7 

width Length of the weir (Circumfer- | L Real > 0.0 Req. 18.7 





ence of the pipe) 























NA = Not Applicable; Req. = Required. 
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3.5.5.6 NWS Gated Weir <gateweir> 


This water mover coding was based on an earlier version of the FLDWAV manual and has 
not been thoroughly tested and verified by OoM staff. Modelers should study the equations 
and use it if they simulate the structure being modeled. 


The gated weir routine was borrowed from the NWS FLDWAV model. The gated weir 
is a weir with a gate that can be lowered to control the flow (Figure 3.9). As the gate is 
lowered, weir flow becomes orifice flow when the gate impinges on the water surface. The 
flow is divided into two flow regimes, rectangular weir flow when the upstream water surface 
elevation is below or at the bottom of the gate and orifice flow when the water surface is 
above the bottom of the gate. The flow equations for weir flow are 


Q =C(CS\WH? (3.43) 


where 


C = user specified coefficient, 

C'S = tailwater correction, 

W = width of the weir, 

z = elevation of the weir crest, 

H,, = H1 — z = upstream head on the weir and 


Q=CxCS xW * Hay2gHu„ (3.44) 


where for orifice flow 
Hg = Gate opening above the weir crest 


The tailwater correction for both weir flow and orifice flow is 


H 3 
Ca =10 = 2783 E — 0.67 (3.45) 
Ha 


for Hy/H, > 0.67 CS = 1.0 otherwise. 


and Ha = downstream head on the weir, H2 — z. 


The attributes of the gated weir watermover are detailed in Table 3.39. 
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Crest Elevation 











Datum ý 





Figure 3.9: Definition sketch of a gated weir. 


In the following example water flows from water body 3156 through a gated weir to water 
body 1358. The crest elevation is 14.5 meters and the gate opening is 4.6 meters. 


<watermovers> 
<gateweir idl = "3156" 2d2="1358" 

crest = "14.5" width = "4.6" c0O5="0.4" c15="0.62" gopen="3.2"> 
</spill> 


</watermovers> 


Table 3.39: Attributes of <gateweir>. 









































Attribute | Definition Dimensions| Variable | Suggested Default Example 
type range 

idl ID of the upstream water body | NA Integer 100000-200000 | Req 153675 

id2 ID of the downstream water | NA Integer 100000-200000 | Req 148322 
body 

wmid ID of the water mover being | NA Integer 200000-300000 | Req 256987 
created 

co5 Discharge coefficient for weir | NA Real 0.35 -0.45 Req 0.42 
flow 

ci5 Discharge coefficient for orifice | NA Real 0.65 - 0.75 Req 0.67 
flow 

control | Specifies what is controlled by | NA String gate or flow flow flow 
controller 

crest Elevation of the weir crest. L Real > Req 13.2 

width Length of the weir. L Real >0 Req. 32.6 

gopen Gate opening (height of the | L Real > 1.0m 5.3 
opening in orifice flow) 

label Label for the weir NA String Any string wm+wmID | Weir 34 


























NA = Not Applicable; Req = Required. 
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3.5.6 Bleeders 


Bleeders are designed to allow small discharges to pass through structures, and may provide 
control over the rate at which the water level recedes from small basins. Three bleeder 
configurations have been borrowed from the MBR model; v-notch, circular, and rectangular. 
All the bleeders consider some downstream submergence effects. The three types of bleeders 
are shown in Figure 3.10. 


3.5.6.1 V-Notch Bleeder <vnotchbleeder> 


Discharge is computed as weir or orifice flow depending on whether the upstream head is 
above the top of the bleeder. For orifice flow (Upstream head above the top of the bleeder) 





Q = 0.6A\/29(H, = Heentroia) (3.46) 


for Ha < Heentroid and 


Q = 0.6Ay 2g9(Hu — Ha) (3.47) 


for Ha > Heentroid 


where 

H,„ = upstream head, 

H, = downstream head, 

Heentroia = elevation of the bleeder centroid, and 
A = the area of the bleeder. 


For weir flow 


Q = 2.5 x CS x tan(0/2)H?° (3.48) 
with the tailwater correction CS = 1.0 for Hg below the bottom of the bleeder and 


_ 2.57 0.385 
Cs = h — (3) | (3.49) 


for Ha > Hiny where 
Ain, = the elevation of the lowest point of the bleeder. 


Attributes of <vnotchbleeder> are listed in Table 3.40. 
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V-Notch Circular Rectangular 


ee ea 


gv 


wal. “4 





Centroid Centroid Centroid 


Invert Invert Invert 
ash Cae _ Datum to 


Figure 3.10: Definition sketch of bleeders. 


The following is the XML code for a v-notch bleeder 
that can move water between water bodies 3 and 5. 





<watermovers> 


<vnotchbleeder id1l="3" id2 = "5" invert = "5.6" top = "6.0" angle = "30"> 
</vnotchbleeder> 


</watermovers> 


Table 3.40: Attributes of <vnotchbleeder>. 
































Attribute | Definition Dimensions| Variable | Suggested Default Example 
type range 

idl ID of the upstream water | NA Integer 100000-200000 | Req. 153675 
body 

id2 ID of the downstream water | NA Integer 100000-200000 | Req. 148322 
body 

wmid ID of the water mover being | NA Integer 200000-300000 | -1 256987 
created 

invert Elevation of the lowest point | L Real 2.0 Req. 13.24 
of the bleeder opening 

top Elevation of the highest point | L Real > 0.0 Req. 15.23 
of the bleeder opening 

angle Angle of the V at the invert | NA Real 0 — 180 Req. 60.0 
in degrees 

label Optional label for the water | NA String Any String wm+wmlID | vbleeder 
mover. 1 


























NA = Not Applicable; Req. = Required. 
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3.5.6.2 Circular Bleeder <circularbleeder> 


This water mover has not been thoroughly tested and verified by the OoM. 


A circular bleeder is a circular opening in a wall or weir. Flow can be weir flow or orifice 
flow depending on whether the upstream head is above the top of the bleeder. For orifice 
flow discharge is 





Q = 0.6Ay2g(Hu = Hcertroid) (3.50) 
for Ag < Heentroid and 


Q= 0.6Ay/29(Hu — Ha) (3.51) 


for Ha > Heentroid 


Weir flow is 








29(H, — H; 
Q = 0.644) g( u ; ‘ners (3.52) 


where Hinvyert = elevation of the bottom of the bleeder and A is the flow area based on the 
upstream head. If Hg > Hinvert then 


Q =0.6A,/29(H,, — Ha) (3.53) 


The attributes of <circularbleeder> are defined in Table 3.41. 


The following XML input will create a circular bleeder with diameter = 0.2 m. and centroid 


at an elevation of 7.6 meters to move water between water bodies 3 and 5. 


<watermovers> 
<circularbleeder id1l="3" id2 = "5" wmID="210" 
centroid = "7.6" diameter="0.2"> 


</circularbleeder> 


</watermovers> 


Table 3.41: Attribute definitions for <circularbleeder>. 
































Attribute Definition Dimensions| Variable | Suggested Default Example 
type range 

id1 ID of the upstream water | NA Integer 100000-200000 | Req. 153675 
body 

id2 ID of the downstream water | NA Integer 100000-200000 | Req 148322 
body 

wmid ID of the water mover being | NA lInteger 200000-300000 | -1 256987 
created 

centroid | Elevation of the centroid of | L Real > 0.0 Req 11.56 
the bleeder opening 

diameter | Diameter of the bleeder L Real > 0.0 Req. 3.24 

label Optional label for the water | NA String Any String wm+wmID | bleeder 2 





mover. 























NA = Not Applicable; Req. = Required. 
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3.5.6.3 Rectangular Bleeder <rectbleeder> 


A rectangular bleeder is a rectangular opening in a wall or weir. Discharge may be either 
orifice or weir flow. The attributes of <rectbleeder> are defined in Table 3.42. Discharge 
is computed as 





Q = 0.6Ay2g(Hu a Ft centroid) (3.54) 
for orifice flow (the upstream head, H,, > top of the bleeder) and 


Q = 0.6Ay/29(Hy — Ha) (3.55) 


for orifice flow with Ha > Heentroia Where H, and H4 are the upstream and downstream heads. 
For weir flow (H,, < top of the bleeder) discharge is 


Q =3.13L Gy — Hasse) (3.56) 


If Ha > Hinvert, the discharge is multiplied by a tailwater correction factor (Brater and 
King, 1996). 


H, = gee pee 
os =|1— (qt) | ven 


The following example creates a rectangular bleeder with height = 0.2 m, width = 1.3 m, 
and elevation of the centroid = 7.6 meters to move water between water bodies 3 and 5. 





<watermovers> 

<rectbleeder id1l="3" id2 = "5" wmID="210" 
centroid = "7.6" height="0.2" width="1.3"> 

</rectbleeder> 


</watermovers> 


Table 3.42: Attribute definitions for <rectbleeder>. 


























Attribute Definition Dimen- | Variable | Suggested Default Example 
sions type range 

id1 ID of the upstream water body NA Integer 100000-200000 | Req 153675 

id2 ID of the downstream water body | NA Integer 100000-200000 | Req. 148322 

wmid ID of the water mover being cre- | NA Integer 200000-300000 | -1 256987 
ated 

centroid | Elevation of the centroid of the | L Real > 0.0 Req 13.24 
bleeder opening. 

height Height of the bleeder opening L Real > 0.0 Req. 2.58 

width Width of the bleeder opening L Real > 0.0 Req. 2.65 

label Optional label for the water | NA String Any String wm+wmlD | rectbleeder 
mover. Al 


























NA = Not Applicable; Req = Required. 
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3.5.7 Bridges 


The Yarnell equation borrowed from the HECRAS technical Reference Manual (Brunner, 
2002) is used in the model to obtain a relationship between the discharge and the upstream 
and downstream heads. An example of its use is two cells separated by a road with a bridge 
spanning an opening in the road. A definition sketch is shown in Figure 3.11 and the at- 
tributes of <yarnel11> are presented in Table 3.43 


The Yarnell equation (Yarnell, 1934) is given in the HECRAS Technical Reference Manual 
(Brunner, 2002) as 


V2 
Hı — Hy = 2K (K + 10w — 0.6) (a + 150") T (3.58) 


where 

Hı = upstream head, 

Hə = downstream head, 

w = ratio of velocity head to depth at the downstream cross section = (V2)*/(2gD2) where 
D> = downstream depth, and 

Və =downstream velocity, 

a = Ratio of the area obstructed by the piers to the unobstructed area at the downstream 
cross section. 


A lookup table is used to define the cross section as a function of head. 


The pier coefficient, K, for various shape piers is listed below 


























Pier Shape Yarnell K Coefficient 
Semi-circular nose and tail 0.90 
Twin-cylinder piers with connecting diaphragm 0.95 
Twin-cylinder piers without diaphragm 1.05 
90-degree triangular nose and tail 1.05 
Square nose and tail 1.25 
Ten pile trestle bent 2.50 











Solving the Yarnell equation for discharge as a function of Hand Hə yields 
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Figure 3.11: Definition of cross sections used with the bridge routine. 
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(3.59) 


Table 3.43: Attribute definitions for <yarnell>. 
































Attribute Definition Dimen- | Variable | Suggested Default Example 
sions type range 

id1 ID of the upstream water body NA Integer 100000-200000 | Req. 153675 

id2 ID of the downstream water body | NA Integer 100000-200000 | Req. 148322 

wmid ID of the water mover being cre- | NA Integer 200000-300000 | Req 256987 
ated 

pshape Yarnell’s pier shape coefficient NA Real 0.5 - 3.0 Req 1.05 

pwidth Total width of al the piers L Real > 0.0 Req 8.62 

botelev Bottom elevation below which | L Real > 0 Req 7.52 
there is no flow 

<da> Depth-Area lookup table. The | NA Real > 0.0 Req see exam- 
first column is the depth and the ple input 





second column is the area of the 
canal cross-section 























NA = Not Applicable; Req. = Required. 
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An example of a data set used for the Yarnell bridge routine is shown below. The bridge 
spans an opening between water bodies 5 and 11. The pier shape is a square nose and tail 
and the total pier width is 2 m. The cross sectional area increases from 0 to 1600 m as the 


depth increases from 0 to 8 m. 


<watermovers> 


<yarnell idYl = "5" id2 = "11" pshape = "1.25" pwidth = "2.0" botelev = 
<da> 

0s O 

1. 200; 

2. 400. 

8. 1600. 

</da> 
</yarnell> 


</watermovers> 


3.5.8 Hydropower<hydropower> 


Hydropower generation is part of water resources development. With the power demand in 
megawatts (MW), the flow is computed as 


Power * 1000 

Q So 

pg * efficiency 

where the power is determined as the demand, or the capacity, whichever is higher. The 
attributes of a <hydropower> object are listed in Table 3.44 


(3.60) 


The following input will create an object to simulate a hydropower plant with a capac- 
ity of 10 MW between water bodies 12 and 45. The demand is specified in a DSS file 
” demand.dss” . 


<watermovers> 
<hydropower wiID = "212" idl = "12" id2 = "45" 
capacity = "10" highhead = "12.3" 
lowhead = "5.6" efficiency = "0.9" 


<dss file= "demand.dss" pn="/L8/ ST 1/FLOW/01JAN1994/1DAY/ NON/" 
mult="0.2"> 
</dss> 
</hydropower> 


<watermovers> 


"499"> 


Table 3.44: 


Attributes of <hydropower>. 












































Attribute Definition Dimen- | Variable | Suggested Default Example 
sions type range 

idl ID of the upstream water body NA Integer 100000-200000 | Req. 153675 

id2 ID of the downstream water body | NA Integer 100000-200000 | Req. 148322 

wmID ID of the water mover NA Integer 100000-200000 | Req. 25456 

label Label for the water mover object | NA String Any string wm+wmID | Hoover 

Dam 

capacity | Plant Capacity, MW ML?T™? | Real >0 Req. 1.5 

lowelev Lowest headwater elevation at | L Real > Req. 8.6 
which plant will operate 

highhead | Design head drop. Used to check | L Real > 0.0 Req 17.6 
the efficient operating range 

lowhead Minimum head drop for plant op- | L Real > 0.0 Req 3.25 
eration 

efficiency Overall plant efficiency as a frac- | NA Real > 0.0 Req. 0.9 
tion 

mult Multiplier for demand NA Real >0.0 1.0 0.78 























The power demand is specified as <const>, as <rc> or in a file in <dss> format as in the example in this 
section. Details are provided in chapter 6 








NA = Not Applicable; Req = Required. 
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3.6 Canal Network - The <network> Element 


HSE is capable of simulating diffusion flow in a canal network, Figure 3.12. The network is 
defined by the input of data that describe 


1. The geometry that defines the location and cross sectional shapes of the canal segments. 


2. Flow in the canal and interactions of the canal with the mesh. These include Manning’s 
n and coefficients for overland flow between the canal and the mesh, seepage into and 
out of the bottom of the canal, and seepage through levees adjacent to canals. 


3. The initial conditions (water levels) in the canal segments. 


Construction of the XML data set to describe and set up the canal network is described 
in the following sections. 


The network can be a single network with loops, trees, and joints with up to four limbs. 
Completely disconnected pieces of canal networks can be simulated using the model, with 
proper boundary conditions. The primary advantage of diffusion flow models over full equa- 
tion models using Preissmann’s (Preissman, 1961) method is error control in the inertia 
terms. In areas such as the Everglades, the enhancement of the solution by the addition of 
the inertia term is negated by the errors in the same term under erratic topography. Any 
computational method used to simulate diffusion flow should be subjected to error control 
using methods suggested by (Lal, 2000b). Even when the model is unconditionally stable, 
use of short segments with large depths, low bed friction values and low slopes may create 
erroneous solutions. 


3.6.1 Canal Data Input Under The <network> Element 


The first step in setting up the canal network model is discretization of the canal network. 
GMS or ARCVIEW using the HSE-GUI can be used to carry out the discretization. Af- 
ter the discretization, the nodal connectivity, nodal coordinates, segment properties and 
segment connectivity are defined under the <network> element in the XML input. The 
subelements that are available to describe a canal network model are shown in Table 3.45. 
A canal simulation also requires a boundary condition file that is described in section 4.2. 


As a general rule, geometry, cross section, and parameter data can all be described using 
the GMS map file. When the parameters of individual segments are not known, and only 
regional values are known, XML input can be used to assign values to groups of segments 
using an index file. A number of sets of parameters are specified in the XML input with each 
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Figure 3.12: A schematic of the canal network. 


set assigned an id number. The index file lists the id of the parameter set to be assigned to 
each segment in the same order that the segments are defined in the GMS map file. In the 
model, values assigned using XML have precedence over values assigned in the GMS map 
file. Values in the map file may then, be modified using XML input without changing the 
map file. 


Table 3.45: Sub-elements and attributes under <network>. 


































































































<Element> or | Definition Dimensions| Variable Suggested range Default Example 

Attribute type 

<geometry> Network geometry file is to be specified. 

file GMS file name NA String Any valid GMS file | Req. enp_can.map 

name 

mult Multiplier for nodal coordinates NA Real >0 1.0 0.3048 

multxs Multiplier for segment cross section values. Of | NA Real Any real 1.0 0.3048 
ten for unit conversion 

<initial> Segment initial condition file to be specified 

file Initial condition file name NA String Any valid file name Req. L8ini.ini 

<network_bce> Network boundary conditions are specified in XML. Details in section 4.2 

<arcs> Properties of canal segments to override the GMS file 

<indexed> Indicates there is a file for indexing of canal segment properties 

file Index file name NA String Any valid file name Req. arcs.index 

<xsentry> Indicates that following information is to override GMS data 

id Entry id for indexed values NA Integer Any integer Req. 3 

label label for the entry NA String Any string Unspecified Big Swamp 

<arcflow> Manning’s n for canal flow is specified 

n Manning’s n for canal flow TL-1/3 Rea 0.0 - 1.0 Req. 0.04 

<arcseepage> parameters for leakage between canal and cell are specified 

leakage_coeff Leakage coefficient in Equation 3.61 NA Rea. 0.0 - 1.0 Req. 0.00045 

<arcoverbank> parameters for overland flow between canal and cell are specified 

bank_height Height of the canal lip L Rea 0.0 - 5.0 Req. 0.6 

bank_coeff Coefficient for flow over the canal lip NA Rea. 0.0 - 1.0 Req. 0.3 

<arclevee> Parameter for seepage through a levee is specified 

coeff Coefficient for seepage between canal and cell | NA Rea. 0.0 - 1.0 Req. 0.003 





through a levee. Overrides levseep1 























NA = Not Applicable; Req. = Required. 
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An example of XML input under the elements listed in Table 3.45 is shown below. Each 
of these inputs is described in detail in the following sections. 


<network> 
<geometry file="mod_can.map" mult = "0.3048" multxs = "0.3048" </geometry> 
<initial file="mod_can.ini" </initial> 
<network_bc file="mod_can.bc" </network_bc> 
<arcs> 
<indexed file="arcs.index"> 
<xsentry id="1"> 
<arcflow n="0.2"></arcflow> 
<arcseepage leakage_coeff="0.000405"> 
</xsentry> 
<xsentry id="2"> 
<arcflow n="0.1"></arcflow> 
<arcoverbank bank_height="0.03" bank_coeff="0.2"> 
</xsentry> 
<xsentry id="3"> 
<arclevee coeff = "0.0005"/> 
<arcflow n = "0.04"/> 
</xsentry> 
</indexed> 
</arcs> 
</network> 














3.6.2 Canal Network Geometry File <geomet ry> 


The name of the canal network geometry file is specified using the <geometry> element. 
It is created in the GMS map format. Data in the canal network file is in either the node en- 
vironment or the arc environment. Data in the node environment gives the two-dimensional 
layout of the canal (Figure 3.12). It specifies the locations of the ends of each canal segment 
and the id number for the segment. The arc environment includes data on each canal seg- 
ment cross section (Figure 3.14) and the values of parameters required to compute flow in 
the canal and the interaction between the canal and the surrounding cells. 


The contents of the geometry file are described in Table 3.46. An example of a canal network 
within a 2-D mesh is shown in Figure 3.13. Table 3.47 and Table 3.48 show a sample geometry 
file for the canal. The canal consists of three segments configured to demonstrate the inputs 
available to describe all the properties of a canal. The subsequent sections describe canal 
flow and an interpretation of the information in the geometry file in Table 3.47 and Table 3.48 


Table 3.46: 


Definition of attributes specified in the canal geometry and boundary condition files in GMS format. 















































Token Definition 
Canal geometry 
map This token indicates that this is the geometry file 
Node environment 

node Indicates the beginning of a node environment. This node environment ends with the end token. id and xy tokens 
are defined within this environment 

xy The x and y coordinate values of the node are provided on this line, with an optional third value not used 

id The ID of the node with the coordinates xy 

Segment or arc environment 

arc Indicates the beginning of the arc environment within which the canal segment properties are defined. The arc 

environment ends with the end token 
Tokens within the arc environment 

id The id of the segment between the specified nodes 

nodes Specifies the two nodes that define the end points of the segment 

type The type of the canal segment. trapezoid is the only option available. The trapezoid properties bottom width, 
bottom elevation, side slope, and Manning’s constant are listed on the same line in order 

flowtype The options available are; 0 for normal flow when the flow length between segments is considered as the distance 
between the center points of the segments; 1 when flow head is assigned at the end of a canal, the segment length 
is doubled to account for the distance from the midpoint of the segment to the end. 2 when the segment length is 
considered to be very small. This is an optional parameter, and the default is 0 

length Length of the segment. This is an optional parameter, because the length is automatically calculated. If the canal 


is meandering, this parameter can be used to give a more accurate length 





leakage_coeff 


Defines the existence of stream-aquifer interaction, and provides the value of the k/ô coefficient. The cell id and 
the length of the segment in the cell are optional parameters 





bank_height 


Defines the existence of stream-overland flow interaction, and provides the ”lip height” defined later. The cell id 
and the length of the segment in the cell are optional parameters 














bank_coeff Value of the coefficient for flow from the cell over the lip to the segment. The cell id and the length of the segment 
in the cell are optional parameters 

levseepl Levee seepage coefficient 1. The cell id and the length of the segment in the cell are required parameters 

levseep2 Levee seepage coefficient 2. The cell id and the length of the segment in the cell are required parameters 
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Figure 3.13: A schematic of the canal network with a levee. 


3.6.2.1 Description Of Nodes 


The four node environments in the geometry file specify the locations of nodes 1, 2, 3 and 4 
in Figure 3.13. Each node is assigned an id number by which it can be referenced. The 0.0 
after each set of coordinates is reserved for a vertical position that is not used in a 2D model. 
The format is shown below. In the sample geometry file (Table 3.47) node 3 is located at 
x =1.10le+ 4 and y = 5.00le + 3. 





NODE 
XY x_coordinate y_coordinate 0.0 
ID node_ID 

END 
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Table 3.47: Sample canal geometry file, part 1 of 2. 





MAP 

BEGCOV 

ACTCOV 

COVNAME "default coverage" 
COVELEV 0.0 

COVATTS GENERAL 

NODE 

XY 2.501E+3 2.501e3 0.0 

ID J 

END 

















XY 5.001le+3 5.001E3 0.0 











XY 1.101le+4 5.001le3 0.0 











NODE 
XY 1.2501e4 1.2501e4 0.0 
ID 4 
END 
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Table 3.48: Sample canal geometry file, part 2 of 2. 
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ARC 

type trapezoid 100.0 498.0 0.5 0.05 
TD ck 

NODES 1 2 

flowtype 1 


length 4250.0 

leakage_coeff 0.0005 7 4250.0 
bank_height 0.5 7 4250.0 
bank_coeff 3.2 7 4250.0 

END 
ARC 

type trapezoid 100.0 496.0 0.5 0.05 
ID 2 

NODES 2 3 

flowtype 1 
length 6200.0 
leakage_coeff 0.0005 8 5100.0 9 1100.0 3 1100.0 
bank_height 0.5 8 5100.0 9 1100.0 3 1100.0 
bank_coeff 3.2 8 5100.0 9 1100.0 3 1100.0 







































































levseepl 0.004 14 5100.0 15 100.0 
levseep2 0.006 14 5100.0 15 1100.0 
END 

ARC 

type trapezoid 100.0 495.0 0.5 0.05 

ID 3 

NODES 3 4 

flowtype 1 


length 13200.0 

leakage_coeff 0.0005 15 6000.0 6 3000.0 12 4200.0 
bank_height 0.5 15 6000.0 6 3000.0 12 4200.0 
bank_coeff 3.2 15 6000.0 6 3000.0 12 4200.0 

END 
ENDCOV 
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3.6.2.2 Canal Cross Sectional Geometry 


The properties of canal segments are defined within the ARC environment. The id’s of the 
nodes defining the ends of a segment are specified after the token NODES. Figure 3.14 shows 
a trapezoidal canal cross section used to simplify a typical canal cross section. In addition 
to the geometry of the canal cross section a number of segment parameters can be specified. 
These are Manning’s n, and the parameters required to describe seepage between a canal 
and adjacent cell through groundwater, levee, or overland flow between the segment and one 
or more cells. These parameters are described in detail in the following sections. 





The straight line distance between nodes is computed internally as the length of a seg- 
ment. If the segment is not straight the length is greater than this computed value and 
the actual length may be specified in the ARC environment after the token length in the 
map file. The flow type for segment 1 is 0, indicating that normal flow calculations are used. 
For segment 2, the flow type is 1 meaning that a flow head is assigned at the end of the canal. 






Slope(s) = x/y 








í Datum í 





Figure 3.14: Trapezoidal canal cross section. 


3.6.3 Stream-Aquifer Interaction 


The values of parameters for calculating the seepage and overland flow between a canal seg- 
ment and the neighboring cell(s) can be specified in the ARC environment (Table 3.48). The 
format is shown below. 
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ARC 
ID segment_ID 



























































NODES defining_node_1 defining_node_2 
type trapezoid [canal_width] [bot_elev] [side_slope_x/y] [Manning] 
leakage_coeff value_of_coeff [cell_no.] [overlap_len] ... [cell_no.] [overlap_len] 
bank_height value_of_coeff [cell_no.] [overlap_len] ... [cell_no.] [overlap_len] 
bank_coeff value_of_coeff [cell_no.] [overlap_len] ... [cell_no.] [overlap_len] 
levseepl value_of_coeff [cell_no.] [overlap_len] ... [cell_no.] [overlap_len] 
levseep2 value_of_coeff [cell_no.] [overlap_len] ... [cell_no.] [overlap_len] 
END 

The .... represent any number of pairs of [cell_no.]  [overlap_len] in the same 


line. They need to be on the same line for the interaction to be based on the coefficient at 
the beginning of the line. 


Figure 3.15 shows a definition sketch used in the conceptualization of stream-aquifer and 
stream-overland flow interaction. 


Stream-Overland 
Flow Interaction 


Lip Height h, 





Stream-Aquifer 
z Interaction 





h Hydraulic 
Conductivity k 











ý Datum í í 





Figure 3.15: A definition sketch showing flow interaction with the canal. 


The token Leakage_coeff is used to represent k/ô from which flow between the aquifer 


and the canal is computed as 


a= “pH h) (3.61) 
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where q = seepage flow per unit length of the canal, 
k = hydraulic conductivity of bottom sediment, 

ô = thickness of the sediment layer, 

p = wetted perimeter of the canal, 

h = water level in the canal segment, 

H = water level in the cell. 

Water may flow in either direction. 


Individual segment stream-aquifer interaction parameter values are specified with the 
token leakage_coeff defined within the ARC environment in the canal geometry file. 
When leakage_coeff is non-zero, canal ground water interaction becomes active. (Lal, 
2001) described critical values of k/5 below which the interaction is insignificant, and above 
which the interaction is full. There is not a single value of k/ô that separates the two regions, 
rather k/ô is a function of dimensionless parameters and depends on the details of the aquifer 
and the canal segment. In segment 3 in the sample geometry file, the coefficient used for k/ô 
is 0.0005, and the length of the segment in cells 15, 6 , and 12 is 6000.0, 3000.0, and 4200.0 
meters, respectively. The sum of these three overlaps is 13200.0 meters, the total length of 
the segment. 


The dotted lines represent any number of pairs of [cell_no.] [overlap_len] in the 
same line. They need to be on the same line for the interaction to be based on the coefficient 
at the beginning of the line. 


3.6.4 Stream-Overland Flow Interaction 


Overland flow between a canal segment and a cell is modeled as weir flow over a ” lip” 
along the edge of the canal segment. The flow is shown schematically in Figure 3.15. The 
lip height is specified after the bank_height token and the weir coefficient, C, after the 
bank_coeff token in the canal geometry file. Flow is computed as 


Q = OCL y gh” 


where 
C = weir coefficient, 
L = length of overlap between the segment and the cell, and 
h = H - (Z + hy), defined in Figure 3.15 
A tailwater correction of h 
o=o 
is applied, where hiw = height of downstream head above the ”lip.” When the head in the 
canal is greater than the head in the cell, flow from the canal to the cell is computed using 
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the same equation with the heads in the canal and in the cell reversed. This streambank 
type water mover is created only if the bank height (h; in Figure 3.15) > 0. 


3.6.5 Levee seepage 


Levee seepage is an important flow component in South Florida modeling. In the SFWMM, a 
separate function had to be developed for levee seepage because of the difficulty of capturing 
it easily using a single transmissivity based flow function. Figure 3.16 shows a cross section 
of the levee illustrating components of seepage. 





Wetland 








Z FIIIT, IZ 
Yyy Layer 2 Mii YY 


Water Level 














Datum 





Figure 3.16: Definition sketch showing levee seepage. 


Figure 3.17 shows the plan view of the same levee along a cell wall. In HSE, cell walls 
that are configured as no-flow walls are often placed along levees. Often a levee is placed on 


only one side of a canal, so that it is necessary to specify which cell interacts with the canal 
by seepage through the levee. 


In the water management model, levee seepage is defined as the total discharge into the 
canal, and is computed using the equation 


qi = Bo + PiAhy + BoAhe (3.62) 


where 

Bo, 61 and bə are constants derived from experimental data, and 
Ah, E hwetland _ Rizana and 

Aho = hwetland — heelt, 
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Figure 3.17: Plan view showing the placement of a levee. 


Aeanal iS the head in the canal, 

wetland is the head in the cell across the levee from the canal, and 

heey is the head in cell that the canal crosses, 

While the coefficients of Equation 3.62 can be derived from experimental data, they are 
typically derived from analytical or numerical models. 

Since HSE is based on water movers that consider only two water bodies at a time, Equa- 
tion 3.62 can be written as 


qı = —G2(Ah; — Ahg) + (81 + b2)Ahı (3.63) 


where (3, + Ba is the coefficient for moving water between the wetland and the canal; (5 
is the coefficient for moving water from the right bank of the canal to the canal, assuming 
the constant o to be negligible in Equation 3.62. The constants 3) and 6; + 62 are the 
coefficients of the new levee seepage water movers. Levee seepage is computed as the sum of 
two water movers; 


Q1 = levseep1 (Hanesiond = ferna) 


Q2 = levseep2 (heen — heanal) 


Coefficients 1evseep1 = ĝı + G2 and levseep2 = —ĝə are defined in the map file 
using the following format. 
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ARC 
type trapezoid canal_width bott_elev side_slope_x/y Manning 














leakage_coeff value_of_coeff 

bank_coeff value_of_coeff [cell_no.] [overlap_len] ... [cell_no.] [overlap_len] 
levseepl value_of_coeff [cell_no.] [overlap_len] ... [cell_no.] [overlap_len] 
levseep2 value_of_coeff [cell_no.] [overlap_len] ... [cell_no.] [overlap_len] 





























ID segment_ID 
NODES defining_node_1l defining_node_2 
END 

















In the sample canal geometry file displayed in Table 3.47 and Table 3.48 as applied to 
Figure 3.13, there is a levee between canal segment 2 and cells 14 and 15. The coefficients 3; 
and (2 are 0.004 and 0.006 and the length of the canal segment along the boundary between 
cells 8 and 2 is 5100.0 m and between 9 and 15 is 1100.0 m. 


3.6.6 Initial Condition File <initial> 


The initial condition file lists the heads in each canal segment at the start of the simulation. 
An example for the canal network shown in Figure 3.13 is shown below. The heads are 
specified so that the depth in each canal segment specified in Table 3.48 is 5.5 meters. 





netinit 
503.5 
501.5 
500.5 











3.6.7 Overriding Canal Properties Using XML 


When a few sets of canal parameters are to be applied to the individual canal segments or 
zones of segments, the element <arcs> with an index file can be used. Each set of canal 
parameters in the XML file is assigned an id number under the <xsentry> subelement of 
<indexed>; see Table 3.45. The entries in the index file specify which set of parameters 
is used for each canal segment. Parameter values specified under <xsentry> and assigned 


CHAPTER 3. HSE MODEL COMPONENTS AND XML INPUT 135 


Table 3.49: Sample indez file. 





DATASET 

OBJTYPE "network" 
BEGSCL 
ND 3 

NAME "segment index" 


























to segments with the index file will override parameter values specified in the map file. The 
index file in Table 3.49 when used with the sample XML input file in subsection 3.6.1 will 
change leakage_coeff in segment 1 from 0.0005 to 0.000405, the bank_height from 
0.5 to 0.03 and the bank_coeff from 3.2 to 0.2 in segment 2. The levee seepage parameter 
<coeff> will be set to 0.0005 and Manning’s n to 0.04 in segment 3. If no values are to be 
overwritten, include a skeleton xsentry ”j” that is assigned to the segments where no values 
are to be modified. This structure is shown in Table 3.50 where xsentry 2 is a ”skeleton” 
entry. Using this xml file with the index file in Table 3.49 will modify no parameters in 
segment 2. 
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Table 3.50: Skeleton rsentry that modifies no values. 





<arcs> 
<indexed file="arcs.index"> 
<xsentry id="1"> 
<arcflow n="0.2"></arcflow> 
<arcseepage leakage_coeff="0.000405"> 





</xsentry> 

<xsentry id="2"> 

</xsentry> 

</indexed> 

<xsentry id="3"> 
<arcflow n="0.2"></arcflow> 
<arcseepage leakage_coeff="0.000405"> 








</xsentry> 
</arcs> 
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3.7 Lakes and Ponds <lakes> 


Lakes and ponds are simulated as independent water bodies in the model. They do not act 
as cells in the regional solution and their only interaction with cells in the mesh is through 
seepage in either direction or through other user created water movers. There are no default 
water movers for lakes. The amount of water in a reservoir is calculated using the equation 
of mass balance 


dH 
As = 5 Qin = 5 Qout (3.64) 


where 

As = the surface area of the lake, 

H = the head in the lake, and 

E Qin and X Qou = rainfall, evaporation, seepage into and out of the lake/pond and the 
flow in any user created water movers. 


Once the storage is calculated, the water level is estimated using a 1-D lookup table or from 
a calculation assuming a cylindrical or parabolic shape for the lake as selected by the user. 


Neither lakes nor ponds are discretized in the model. Lakes are larger water bodies, and 
the mesh cell discretization can surround the lake with cell walls in contact with the lake 
boundary. Ponds are smaller water bodies, and occupy a small space inside a triangular 
model mesh cell. Ponds situated within a single cell are considered to be sufficiently small 
such that they do not disrupt the 2-D flow although they do decrease the area of the cell by 
the area of the pond. Whether a water body is treated as a lake or a pond is specified by 
the user. Figure 3.18 shows a definition sketch of a reservoir, to which water is fed from an 
upstream river. Figure 3.19 shows the discretization around a lake and the placement of a 
pond entirely within a cell. 


Both lakes and ponds are defined in the model as water bodies. However, there are no 
default water movers for lakes, unlike the case of cells or segments. Lakes and ponds are 
defined under the <lakes> element in the XML input. Valid sub-elements and attributes 
within <Lakes> are shown in Table 3.51 with additional details in Table 3.52 and Table 3.53. 

A sample XML input for a lake and a pond is shown in Table 3.54. In this input Lake 
Kalawewa is a lake since ”supplant” < 0. The relationships between stage, area and volume 
are defined by 1-D lookup tables; rainfall is a time series in a DSS file; RefET is constant, 
and ET is greater over shallow water than deep water with 4.3 meters (specified by the user) 
being the depth dividing shallow and deep water. Frog pond (supplant = +2) has daily 
rainfall in a dss file and a constant RefET. There is less ET as a fraction of refET than 
in the lake because of the smaller coefficients under <1itZoneET> and the dividing depth 
between deep and shallow water (specified by the user) is only 2.8 meters. 
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River/Reservoir 
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Figure 3.18: Schematic diagram of a reservoir formed in a river. 
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Figure 3.19: 


Discretization around a lake and a pond 
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Table 3.51: Sub-elements and attributes used to define lake properties under the <lake> element. 



























































<Element> At- | Definition Dimen-| Variable | Suggested Default | Example 

tribute sions type range 

<lake> Indicates a new lake/pond water body is to be created 

id Lake or Pond ID NA Integer Any valid | Req. 234625 

long integer 
label Name of the lake NA String Any valid | undefined | Ocala 
string 

head0O Initial head in the lake L Real Any real Req. 13.64 

top Full supply level - not neces- | L Real Any real 1000 17.32 
sarily the same as ’ top” in Ta- 
ble 3.52 

supplant Indicates whether the wb is a | NA Integer < 0 for lake, | -1 -2 
lake or a pond > 0 for pond 

<parabolic> Indicates that lake area, volume, and stage are computed assuming a parabolic shape. 
Details in Table 3.52 

<cylinder> Indicates that lake area, volume and stage are computed assuming a cylindrical shape. 
Details in Table 3.52 

<sv> Indicates that the stage-volume relationship follows in a 1-D lookup table 

<sa> Indicates that the stage-area relationship follows in a 1-D lookup table 

<refet> Indicates that the reference ET is specified 

<rain> Indicates that rain is specified 





Details on specifying input 


explained in chapter 6 


data for <refet> and <rain> in <const>, <rc>, and <dss> formats is 





<EvapRainStressors> 


Parameters for calculation of ET are specified. Details in Table 3.53 





<lake_bc> 


Lake boundary conditions are defined. Details in section 4.4 








NA = Not Applicable; Req = Required. 
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Table 3.52: Elements and attributes used to define lake area and volume under the <lakes> element. 
































<Element> or | Definition Dimensions | Variable | Suggested Default | Example 

Attribute type range 

<parabolic> Indicates that lake area, volume, and stage are computed assuming a parabolic shape 

toparea Area of the lake surface when | L? Real Any valid real | Req. 6.3E+5 
full 

top Head of the lake when full L Real Any valid real | Req. 23.56 

bot Elevation of the lake bottom L Real Any valid real | Req. 4.87 

<cylinder> Indicates that lake area, volume and stage are computing assuming a cylindrical shape 

toparea Area of the lake surface when | L? Real Any valid real | Req. 6.3E+5 
full 

bot Elevation of the lake bottom L Real Any valid real | Req. 4.87 























NA = Not Applicable; Req. = Required. 
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3.7.1 Rainfall and Evapotranspiration 


Two major components of the water budget of a lake or pond are precipitation and evapo- 
transpiration. While the contribution of precipitation is straightforward, evapotranspiration 
depends on the surface area of the lake and the depth of the water in addition to the RefET 
values assigned to the water body. In order to account for the different rates of evapotran- 
spiration over shallow and deep water, the total ET over the lake is calculated as 


ET Volume = |swcoef x (DryArea + ShallowArea) + owcoef x DeepArea| Ref ET 
(3.65) 


where 

DryArea = the area of the lake that is dry, 

ShallowArea = the area of the lake that is shallow, 

DeepArea = the area of the lake that is deep, 

and the coefficients and the dividing depth between deep and shallow water are specified 
under <EvapRainStressors> as described in Table 3.53. 























Table 3.53: Elements and attributes used to define <EvapRainStressors>. 

<Element> or | Definition Dimensions | Variable | Suggested Default | Example 

Attribute type range 

<litZoneET> Lake ET parameters are specified 

lakeID ID of the lake NA Integer Any valid wb | Req. 138245 

ID 

owcoef Open Water coefficient for | NA Real Any real Req. 1.00 
RefET 

swcoef Shallow water coefficient for | NA Real Any real Req. 0.85 
RefET 

swdepth Depth that divides shallow | L Real Any real Req. 5.5 





and deep water 























NA = Not Applicable; Req = Required. 
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3.7.2 Lake Seepage <lake_secepage> 


Seepage into and out of lakes is computed using <lake_seepage> water movers that are 
defined by the user in the main <hse> XML environment under the <watermovers> 
element. If <lake_seepage> is not defined, there is no mechanism for leakage. Seepage 
can occur from the lake to one or more cells and/or from cells to the lake. The rate of 
seepage is computed as 


Seepage = LCD(H, — Ha) (3.66) 


where L and C are the length and conveyance as described in Table 3.55, 

H,, and Hg are the higher and lower heads in the lake and the cell, and 

D = the depth of water in the lake if the head in the lake is higher or (Heen-Hiakebottom) if 
the head in the cell is higher. 

The XML input to create a <lake_seepage> water mover is defined in Table 3.55. Ta- 
ble 3.56 shows an XML file that defines seepage between Lake Kalawewa (LakeID 235823) 
and wb 597351 and between Frog Pond (LakeID 248795) and wb 746533. 
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Table 3.54: Sample XML input for lakes and ponds. 
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<?xml version="1.0"> 
<sfrsm version="1.0"> 





<lakes> 
<lake id="235823" label="Kalawewa" head0="504.0" supplant="-2" 
<SV> 
O30 0.0 
400.0 3.0e8 
600.0 10.0e8 
</sv> 
<sa> 
0.0 0.0 
400.0 .5e7 
600.0 4.2e7 
</sa> 
<rain> 


<dss file="SFPrec.dss" pn="/ENP/Regl//EVAPI/1DAY/SFCalc/" 
mult="0.3048" units="feet" </dss> 
</rain> 
<refet> 
<const dbintl="1440" value="0.14" mult="0.3048" </const> 
</refet> 
<EvapRainStressors> 
<litZoneET lakeID="324572" owcoef="0.8" swcoef="0.9" 
swdepth="4.3" </litZoneET> 
</EvapRainStressors> 
</lake> 




















<lake id="248795" name="Frog Pond" head0="504.0" supplant="2" 
<parabolic toparea="6.3e+5" top="510.0" bot="490.5"> </parabolic> 
<rain> 
<dss file="FrogPrec.dss" pn="/Areal/Frog//RAIN/1DAY/TippBucket/" 
type="PER-CUM"label="gaugel" </dss> 
</rain> 
<refet> 
<const dbint1l="1440" value="0.28" mult="1.0" </const> 
</refet> 
<EvapRainStressors> 
<litZoneET lakeID="31568" owcoef="0.6" swcoef="0.85" 
swdepth="2.8" </litZoneET> 
</EvapRainStressors> 
</lake> 

















</lakes> 





dbintl="1440" 








Table 3.55: Elements and attributes used to define the lake seepage water mover. 












































<Element> or | Definition Dimen- | Variable | Suggested | Default Example 
Attribute sions type range 
<lakeseepage> | Indicates the creation of a <lakeseepage>watermover. 
lakeID Lake ID number NA Integer Any valid | Req. 123723 
lake ID 
wbID Cell ID number that in- | NA Integer Any valid | Req 469852 
teracts with lake cell ID 
wmID Water Mover id NA Integer Any valid | -1 35469 
wm ID 
label Label for the Water | NA String Any string seepage- Lake Wales 
Mover lakewm+wmlD | seepage 
length Length of the shoreline | L Real > 0.0 Req. 689.4 
in contact with the cell 
conveyance Transmissivity of | T7! Real > 0.0 Req. 0.0054 
aquifer as defined in 
Equation 3.66 


























NA = Not Applicable; Req. = Required. 
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Table 3.56: Sample XML input for lake seepage. 





<watermovers> 
<lakeseepage> 
<lakeseepage lakeID ="235823" wbID="597351" 
length="1000.0" conveyance="0.05"> 
</seepage > 
<seepage lakeID ="248795" wbID="746533" 
length="2000.0" conveyance="0.08"> 
</seepage > 
</lakeseepage> 
</watermovers> 
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3.8 Storage and Stage-Volume Converters - The XML <svconverter> 
Element 


The South Florida landscape is relatively flat when compared with the rest of the country. 
But within the range of elevations close to the average ground elevation, the hydrological 
characteristics may change significantly. Some of the characteristics that change rapidly 
are the water storage volume per unit change in head, the ET rate, and the overland flow 
roughness. Stage-volume converters <svconverter> have been developed to allow a more 
accurate representation of the volume of water stored at different water levels. Depending on 
the area under water, wetlands can store variable amounts of water at various depths. A flat 
ground with a designated storage coefficient below ground level and the assumption of open 
water above ground level is generally a poor representation of wetland storage conditions. 
However, this has been the standard method used to conceptualize water storage above and 
below ground. This section describes ways of representing elevation-storage relationships 
that better represent the micro-topography in the cell of a regional model. Figure 3.20 
shows a section of a cell with an undulating ground surface. In the XML representation, the 
stage-storage conversion behavior is defined in the <mesh> environment using the element 
<svconverter>. A single <scvonverter> can be defined for the entire model, or the 
cells can be indexed to use different converters in different areas. Examples of both are given 
in the following sections. 


The same idea can be extended to capture the cross-sectional area versus stage charac- 
teristics of canal segments. Canal data are specified using a number of methods. Many 
times, cross sections are approximated using rectangular and trapezoidal shapes. At other 
times, lookup tables are used. The SV converter is used to translate any type of cross section 
data to give the required area and the width properties. The reverse translation is carried 
out by the same converter without any loss of mass. The SV converter simplifies many of 
the complexities associated with model geometry. 


3.8.1 Representation Of A Flat Ground Surface 


In most early representations of a flat ground surfaces, the volume of water in a cell below 
the ground level is computed as 


(H — zp)se, (3.67) 
and the volume above ground is represented as 


(H — z) + (z — zgB)sec, (3.68) 
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Figure 3.20: Describing stage-storage characteristics in micro-topography. 


where 

H = the head, 

z = the ground surface elevation, 

zp = the elevation of the bottom of the aquifer, and 
Se = the storage coefficient. 


If this behavior is to be imposed for the entire model, the following could be defined 
within the <svconverter> environment. 


<svconverter> 
<constsv sc="0.2"> </constsv> 
</svconverter> 


3.8.2 Representation Using A Lookup Table 


The actual ground surface elevation varies between the highest and lowest points in a cell. 
Until the water starts to collect as puddles, at the lowest elevations, the water storage is 
computed as (z — zp)s-. As the water level rises above the lowest point (Z-Z; in Figure 3.20), 
the volume of water stored above the lowest point can be measured as a function of depth 
above this elevation. The water stored in this layer per unit thickness is 


S(d) = $ a4(H) + (1 - aa(H))se(H) (3.69) 


where 
a4(H) = fraction of open water area at a water level of H and 
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Se(H) = storage coefficient of solid ground. 


When the water level is above the highest peak (7+ Z, in Figure 3.20), the added volume 
has a storage coefficient of 1.0. The total volume of water can be computed by integrating 
(3.69) over depth. This integral, which represents the total volume of water stored above the 
lowest ground depression of a cell per unit area of a cell, is represented in the model with a 
stage-volume converter using the elements and attributes in Table 3.57. 


Below the range of the <lookupsv> stage-volume converter, the available storage in 
the soil is (H — datum) x se. Beginning at the elevation (ground surface - below) the storage 
in the lookup table is added to the storage below that elevation to compute the total stor- 
age. The highest elevation at which the lookup table applies is (ground surface + above). 
Assuming a ground elevation of 10 m above the datum, the total storage at elevation 10.6 
m in the example below is 


storage = (10 — 1.5)(0.2) + 0.24 = 1.94 


where 0.24 m is the storage interpolated at a depth of 0.6 m in the lookup table <sv>. 


Table 3.57: Elements and attributes used to define a <lookupsv> SV converter in the <mesh> environment. 






































<Element> | Definition Dimensions | Variable Suggested | Default | Example 
or Attribute type range 
<lookupsv> | Designates an <lookupsv> stage-volume converter. 
sc Storage coefficient below the | NA Real 0-1 Req. 0.23 
SV converter, se 
below Depth of the lowest point | L Real 0-5 Req 1.3 
below the ground surface at 
which the lookup table ap- 
plies 
above Height of the highest point | L Real 0-5 Req. 1.3 
above the ground surface at 
which the lookup table ap- 
plies 
<sv> Table of depth(d) and cumulative storage values. d is defined as H — (Z — below). The SV 


converter is applied between Z — below and Z + above where Z is the ”surveyor’s” ground 


elevation 








NA = Not Applicable; Req. = Required. 
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The curve in Figure 3.20 describes the storage properties of a cell as a function of the 
head and the average ground elevation for the cell. If the entire model domain is to use the 
same curve, but each cell adjusted to its own ground elevation, the following example can 
be followed. 


<lookupsv sc="0.2" below="1.5" above="1.0"> 


<sv> 
0.0 0.0 
042 0.04 
0.4 O12 
0.8 0.36 
1.0 0.56 
2.0 1.56 
31.0) 290 

</sv> 
</lookupsv> 


The attributes <below> and <above> can be used to assign the same SV behavior to 
different terrain when the vertical undulations are greater or less. These values specify the 
b PG pi 


vertical extent of the lookup table about the ”surveyor’s” ground surface (the elevation of 
the ground surface if it were leveled). 


3.8.3 Use Of More Than One Type of SV converter 


If a mixture of two or more types of SV converters is to be used, indexing is available as 
shown in the following example. 


<svconverter> 
<indexed file="sv.index"> 
<entry id="1" label="const"> 
<constsv sc="0.2"> </constsv> 
</entry> 
<entry id="2" label="lookup"> 





<lookupsv sc="0.2" below="1.5" above="1.0"> 


<sv> 
0.0 0.0 
0.2 0.04 
0.4 0.12 
0.8 0.36 
1.0 0.56 
2.0 1.56 
3.0 2.56 
</sv> 
</lookupsv> 
</entry> 
</indexed> 
</svconverter> 


In the example, the index file ”sv.index” is an ASCII file in GMS format describing the 
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assignment of the two types in this example to the cells in the mesh. 


Chapter 4 


Boundary Conditions 


As with any model, RSM simulations depend heavily on the forcing functions that drive the 
model. The major forcing functions are rainfall, evapotranspiration, inflow from rivers and 
streams, known outflows from the model domain, and the specification of known heads dur- 
ing the simulation period. These functions generate the hydraulic conditions that are used to 
set initial head conditions as well as boundary conditions. The boundary conditions specify 
the inflows and outflows at specified locations during the period of simulation. Much of the 
effort in building a model is the collection and preparation of data to accurately represent 
these processes. 


The input data needed to specify initial and boundary conditions can be a limiting factor 
in creating accurate RSM models. Good quality input for initial and boundary conditions 
are essential for successful system simulation. Proper conceptualization and quantification of 
these conditions can be accomplished if sufficient good quality data exists and enough knowl- 
edge exists about the hydraulic behavior of the system being simulated. In this Chapter, 
the boundary conditions for regional 2-D flow, networks, and lakes are presented. 
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4.1 Boundary Conditions For Two-Dimensional Flow <mesh_bc> 


Boundary condition (BC) for 2-D overland flow and 2-D groundwater flow are described in 
this chapter. Both 2-D overland flow and groundwater flow boundary conditions can be 
specified using cells or cell walls. The most commonly used boundary conditions are flow 
boundary conditions and head boundary conditions. All 2-D BC’s for mesh cells and walls 
separating cells are defined within the <mesh_bc> environment as described in detail and 
illustrated below. 


Figure 4.1 shows a 3x3 mesh with the boundary conditions available for cells and walls in- 
dicated. The constant <wallghb> boundary condition is applied to the walls defined by 
nodes 1, 5, 9. Walls defined by nodes 9, 13, 14, 15 , and 16 also has a <wallghb> boundary 
condition but the head value is interpolated according to specified weighting between two 
time series. A <wallhead. boundary condition is applied to the walls defined by pairs of 
nodes 1-2, 2-3, 3-4, and 8-12 with a head value linearly interpolated between a constant and 
a time series. A <walluf> boundary condition is indicated for wall 12-16 although this 
boundary codition is not yet fully implemented. Overland flow is blocked by a <noflow> 
boundary condition along the walls defined by nodes 2, 6, and 11. Cell boundary conditions 
are a <well> pumping a time series of flows from cell 3, a <cellheasd> specified by a 
rating curve in cell 7, and a <cellghb> with a constant head in cell 4. These boundary 
conditions and the the XML input required to apply them are described in detail in the 
following sections. 


Time dependent boundary conditions for general water bodies such as canal segments, lakes 
and ponds as well as 2-D flow can be specified as a time series in file formats described later 
in section 6.1 . All boundary conditions except <cellhead> and <segmenthead> are 
implemented by creating water mover objects designed to move water in such a way as to 
achieve the prescribed flow or head. 


4.1.1 Available Boundary Condition Types 


Both cells and cell walls can be used to impose 2-D boundary conditions. Walls are ideal 
to assign head and general head type BC’s. Cells are ideal for discharge type BC’s. When 
assigning values to a series of cells or walls, methods are available to specify the locations of 
the cells or the walls, and assign values obtained by interpolating between given time series 
or constant values. These methods can save time by not requiring the user to enter a long 
list of values for individual cells or walls. The available cell based boundary conditions are 
listed in Table 4.1 and wall based BC’s are shown in Table 4.2 and Table 4.3. The methods 
available to define the locations of the walls and cells to which the boundary conditions apply 
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are described in subsubsection 4.1.2.1, while subsubsection 4.1.2.2 describes the methods 
available to define the available interpolation methods and the interpolation weightings. 
There are numerous options for specifying cell and wall boundary conditions. These options 
will be explained along with example XML input to demonstrate each. These descriptions 
and examples should clarify the information in Table 4.1 through Table 4.3. 


Table 4.1: Elements and attributes used to describe two-dimensional boundary conditions applied to cells in the <mesh_bc> 


environment. Element names are highlighted. 






























































<Element> or | Definition Dimen- Variable | Suggested Default Example 

Attribute sions type range 

<well> Indicates a constant or time series of flow into or out of a cell 

cellid ID of the cell that receives the flow NA Integer Any valid cell ID | Req. 234625 

wellid Optional user-defined ID for the cell to be used later | NA Integer Any valid cell ID -1 234625 

in water budget output 

label Optional label used to describe the flow NA String Any string well-cell +cellID Water Supply 
Well 

<cellhead> Indicates a constant or time series head value assigned to a cell 

id ID of the cell whose head is specified NA Integer Any valid cell ID Req. 546987 

beid ID assigned to the BC NA Integer Any valid cell ID | -1 234625 

label Optional label to describe the boundary condition NA String Any string headbc-cell +ID STA-—3 

<cellghb> Indicates a constant or time series head value assigned to a general head boundary condition for a cell 

id ID of the cell that the BC is applied to NA Integer Any valid cell ID Req 546987 

beid ID assigned to the BC NA Integer Any valid ID -1 35896 

value The coefficient in Equation 4.5 L?TT! Real Any valid real Req. 0.35 

label Optional label to describe the boundary condition NA String Any string ghb-cell+ID Lake Cal- 
loway 








Each of the elements <well>, <cellhead> and <cellghb> has the fo 
and <rc>. These elements and their attributes are described in detail in section 6.1; Note: NA = Not Applicable; Req. = Required. 





lowing sub-e 





ements available for specifying the flow or head: <const>, <dss>, 
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Table 4.2: Elements used to define the <wallhead> and <wallghb> boundary conditions applied to walls in the <mesh_bc> 


environment. The elements are in shaded cells. 


























the boundary condition 














+idcell 





<Element> or At- | Definition Dimensions | Variable | Suggested Default Example 

tribute type range 

<wallhead> Indicates a constant or time series head value assigned to a wall or walls. 

section Specifies whether overland flow, | NA String ol, gw, ol_gw ol_gw ol_gw 
groundwater flow or both are 
affected by the BC 

label An optional label identifying | NA String Any String wallhead Tampa Tide 
the boundary condition 

<wallghb> Indicates a constant or time series general head boundary condition assigned to a wall or walls 

value The value of the coefficient for | LT! Real Any real Req. 0.046 
<wallghb> in Equation 4.2 

label An optional label identifying | NA String Any String wallghb-cell Lake Level 





The following sub-elements and attributes are available under both <wallhead> and <wallghb>. 





<walllist> 


Indicates that the walls subject to the boundary condition are specified by a block of text containing pairs 
of nodes, each pair representing a wall 























of contiguous nodes specifying a continuous wall 


A block of text within | Pairs of node ids NA Integer Pairs of adjacent | No default 234625 
<walllist>. nodes 456987 
256354 
458657 
<nodelist> Indicates that the walls subject to the boundary condition are specified in a block of text containing a list 





A block of text within 
<nodelist>. 


A list of node ids 





NA 





Integer 





A series of adja- 


cent nodes 





No default 





235467 
546575 
345764 
867456 
654763 





Sub-elements available for specifying the method of interpolating constant or time series heads to apply to wall boundary conditions 
<wallhead> and <wallghb> are defined by the elements and attributes in Table 4.5 





Sub-elements available for specifying the head for the wall boundary conditions <wallhead> and <wallghb> are <const>, 
<dss>, and <rc>. These are described in detail in chapter 6 








NA = Not Applicable; Req. = Required. 
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Table 4.3: Elements and attributes used to define the <noflow> and <walluf> boundary conditions applied to walls. 
elements are in shaded cells. 


The 























slope in Equation 4.3 














<Element> or | Definition Dimen- | Variable Suggested Default | Example 

Attribute sions type range 

<noflow> Indicates that flow through a wall or walls will be blocked 

section Specifies whether overland | NA String ol, gw, ol_gw | ol_gw ol_gw 
flow, groundwater flow or both 
are affected by the BC 

<walluf> Indicates a uniform flow boundary condition applied to a wall or walls 

value The value of the coefficient for | NA Real Any real Req. 0.014 





The following sub-elements and attributes are available under both <noflow> and <walluf> 



































<walllisgt> Indicates that the walls subject to the boundary condition are specified by a block of text 
containing pairs of nodes, each pair representing a wall 
A block of | Pairs of node ids NA Integer | Pairs of adja- | No de- | 234625 
text within cent nodes fault 456987 
<walllist>. 256354 
458657 
<nodelist> Indicates that the walls subject to the boundary condition are specified in a block of text 
containing a list of contiguous nodes specifying a continuous wall 
A block of | A list of node ids NA Integer | A series of ad- | No de- | 235467 
text within jacent nodes. fault 546575 
<nodelist> 345764 
867456 
654763 








NA = Not Applicable; Req. = Required. 
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4.1.2 Defining Attributes Of 2-D BC’s 


The example XML input in Table 4.4 demonstrates many of the elements and attributes 
available to define 2-D boundary conditions. The application of these specifications on a 
mesh are indicated in Figure 4.1. The following sections refer to this example XML input 
to demonstrate the application of the boundary condition options described. The relevant 
XML input from Table 4.4 is also included in the description of each option. 


; between headbc.dss 
ae A and constant = 13.6 


constant value of 17.43 


Nodes — 
q 
3 IS 
<well> | 
` pumps.dat | & 
<wallghb> . E | >- <wallhead> 
coefficient = 0.47 ie? ‘linear interpolation 
3 | 
| 


x 
S 
x 
_7~ <noflow> overland 
< flow is blocked ^, 
| \ 


<walluf> 
slope = -0.12 





<wallghb> 

coefficient = 0.064 

weighted interpolation between 
Loc1GHB.dss and Loc2.dat 


Figure 4.1: Illustration of the application of 2D Mesh Boundary Conditions. 


4.1.2.1 Definition Of BC Location <nodelist> and <walllist> 


A cell boundary condition is applied to a single cell specified by the cell ID as demonstrated 
by the <we11> discharge into cell 3 defined in Table 4.4 and shown in Figure 4.1. Wall 
boundary conditions often need to be applied to a large number of walls such as when a 
road blocks overland flow or one boundary of a model domain is subject to a tidal head. 
The location and application of a wall boundary condition to one or more walls is specified 
under one of two sub-elements. Under <walllist> pairs of nodes are listed with each 
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Table 4.4: Example XML input for 2-D boundary conditions. 


<mesh_bc> 
<wallhead section="o0l_gw" label="STA-3"> 
<walllist> 12 2 3 3 4 8 12 </walllist> 
<endpts> 

<entry id="1" 
<dss file="headbc.dss" 
pn="/HSE/T C03/HEAD/01JAN1994/15MIN/CALC/"> </dss> 

</entry> 

<entry id="2"> 
<const value="13.6"> </const> 


</entry> 
</endpts> 
</wallhead> 
<cellghb id="4" value="0.15" label="Lake Isabel"> 
<dss file="PondHead.dss" pn = "/AvgHead/Pond/Stage/05AMR1993/1DAY/normal/ "dbint1="1440" > 
</dss> 
</cellghb> 
<well cellid="3" wellid="7658" label="Pump Station 8"> 
<dss file="Pump8.dss" pn = "/NormalRules/Pump8/Flow/05AMR1993/1DAY/normal/" 
mult="0.02831685" dbintl="1440">"> 
</dss>"> 
</well> 
<wallghb value="0.064"> 





<nodelist> 9 13 14 15 16 </nodelist> 
<wts2pts> 
<entry id="3"> 
<dss file="Loc1GHB.dss" 
pn="/Locl1//Head/02FEB1994/15MIN//"> </dss> 
</entry> 
<entry id="4"> 
<dss file="Loc2.dss" pn = "/AvgHead/Loc2/Stage/05AMR1993/1DAY/normal/ "dbint1="1440" 
</dss> 
</entry> 
<wts> 1.0 0.2 0.8 0.0 </wts> 
</wts2pts> 
</wallghb> 
<cellhead id="7" bcid="42" label="Long Pond"> 
<re id="12> </re> 
</cellhead> 
<noflow section="o0l"> 
<nodelist> 2 6 11 </nodelist> 
</noflow> 
<wallghb value="0.47"> 
<nodelist> 1 5 9 </nodelist> 
<uniform> 
<const value="17.43"> </const> 
</uniform> 
</wallghb> 
<walluf value="-0.12"> 
<nodelist> 12 16 </nodelist> 
</walluf> 
</mesh_be> 
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pair specifying a wall. These walls need not be adjacent. Under <nodelist> a continuous 
series of adjacent nodes is listed defining one or more adjacent walls to which the boundary 
condition is applied. Only a continuous series of walls may be specified under <nodelist>. 


In the example XML input in Table 4.4 and shown below, the <wallhead> boundary 
condition applies to the walls designated by pairs of nodes 1 — 2, 2 — 3, 3 — 4, and 8 — 12 as 
shown in Figure 4.1. Note that the walls need not be contiguous. The <noflow> boundary 
condition for overland flow in Table 4.4 and below applies to the continuous wall defined by 
contiguous nodes 2, 6 and 11. The <noflow> and <wallhead> boundary conditions may 
be applied to overland flow, groundwater flow, or both as specified by the value assigned to 
<section> as described in Table 4.2 and Table 4.3. 


<mesh_bc> 
<wallhead section="0l_gw" label="STA-3"> 
<walllist> 12 2 3 3 4 8 12 </walllist> 
<endpts> 
<entry id="1" 
<dss file="headbc.dss" 
pn="/HSE/T C03/HEAD/01JAN1994/15MIN/CALC/"> </dss> 
</entry> 
<entry id="2"> 
<const value="13.6"> </const> 
</entry> 
</endpts> 
</wallhead> 
<noflow section="o0l"> 
<nodelist> 2 6 11 </nodelist> 
</noflow> 
</mesh_bc> 




















Table 4.5: Elements and attributes used to assign interpolation weighting to the <wallhead> and <wallghb> boundary 
conditions. Element cells are shaded. 





<Element> or | Definition Dimen- | Variable Suggested Default | Example 
Attribute sions type range 




















<wallhead> or | Indicates a constant or time series wall general head or wall head 
<wallghb> boundary condition value assigned to a wall or walls 














The following interpolation specifications apply to both <wallhead> and <wallghb> 
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<uniform> Each wall is assigned the same value specified by <const> or by a time series 

<wt s2pt> Entries for interpolation will be specified 

<wts> A sub-element under <wts2pt> that indicates the interpolation values will be specified in a block 
of text within the <wt s> environment. The first weight must be 1.0 and the last 0.0 

A block of real | The interpolation weights as- NA Real >0.0 and < 1.0 | No 1.0 0.65 0.5 

numbers is in- | signed to the walls spec- default | 0.4 0.0 

serted. ified by <nodelist> or 
<walllist>. One entry for 
each wall 

<entry> Indicates that a constant or time series of head values will be specified. Two entries are required; 
one to specify the head for the first wall and one for the last 

<id> The ID of the entry NA Integer | Any valid integer | Req. 234 

<endpts> Entries for linear interpolation will be specified 

<entry> Indicates that a constant or time series of head values will be specified. Two entries are required; 
one to specify the head for the first wall and one for the last 

<id> The ID of the entry NA Integer | Any valid integer | Req. 234 























NA = Not Applicable; Req. = Required. 
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4.1.2.2 Interpolation Used For Wall Boundary Conditions 


The <wallghb>, and <wallhead> boundary conditions may be assigned to walls based 
on a designated weighting pattern. The head value is assigned along the entire length of each 
wall defined by two nodes. The interpolation is from wall to wall and not within one wall. 
The available options for assigning weighting values of these boundary conditions to walls 
are specified in Table 4.5. <uniform> indicates that all walls have the boundary condition 
equally applied as shown by the application of a wall general head boundary condition 
<wallghb> to the wall defined by nodes 1, 5, and 9 as shown below and in Table 4.4 and 
Figure 4.1. 


<mesh_bc> 
<wallghb value="0.47"> 
<nodelist> 1 5 9 </nodelist> 
<uniform> 
<const value="17.43"> </const> 
</uniform> 
</wallghb> 
</mesh_bec> 


With the <wts2pt> option, a list of weights and a corresponding list of walls are 
specified. The list of walls may be specified under either <nodelist> or <walllist>. 
The values of the boundary condition at the first and the last wall in the list are specified 
under <entry> as a constant, time series, or a rating curve. The values at the other walls 
are determined by non-linear interpolation from the end wall values using the weighting 
specified under <wts>. For an intermediate weighting value of x for the jth wall, the 
boundary condition value assigned to the jth wall is x*(value at the first wall)+(1-x)*(value 
at the last wall). The first and last entries under <wt s> must be 1.0 and 0.0. In the example 
XML input below, the <wallghb> boundary condition at the wall defined by nodes 14 and 
15 is 0.8*(the value in LoclGHB.dss) + 0.2*(the value in Loc2.dat). An example of the use 
of <wts2pt> is shown below and in Table 4.4 for a <wallghb> boundary condition. 


<mesh_bc> 
<wallghb value="0.064"> 
<nodelist> 9 13 14 15 16 </nodelist> 
<wts2pts> 
<entry id="1"> 
<dss file="Loc1GHB.dss" 
pn="/Locl1//Head/02FEB1994/15MIN//"> </dss> 
</entry> 
<entry id="2"> 
<dss file="Loc2.dss" 
pn = "/AvgHead/Loc2/Stage/05AMR1993/1DAY/normal/ "dbint1="1440" > 
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</dss> 
</entry> 
<wts> 1.0 0.2 0.8 0.0 </wts> 
</wts2pts> 
</wallghb> 
</mesh_bc> 


With the <endpts> option, the values of the boundary condition at the first and last wall 
are specified under <entry> as a constant, time series, or a rating curve. The values at 
the other walls are determined by linear interpolation from the end wall values. An example 
of the use of <endpts> is shown below and in Table 4.4 for the <wallhead> boundary 
condition. In the example below, the wall defined by nodes 2-3 has a head boundary condition 
applied that is 0.667* (the value in headbc.dss) + 0.333* (13.6). 





<mesh_bc> 





<wallhead section="o0l_gw" label="STA-3"> 
<walllist> 1 2 2 3 3 4 8 12 </walllist> 
<endpts> 


<entry id="1" 
<dss file="headbc.dss" 
pn="/HSE/T C03/HEAD/01JAN1994/15MIN/CALC/"> </dss> 

</entry> 

<entry id="2"> 
<const value="13.6"> </const> 

</entry> 

</endpts> 
</wallhead> 
</mesh_bc> 








4.1.2.3 Time Series Data Format Used For Data Entry At Boundaries And Other Locations 


A number of data formats are used to enter time series data into the model. These data 
formats may be used to specify data for boundary conditions and forcing functions applied 
to cells, segments, lakes, walls, water movers or similar objects. The formats available 
are <dss>, <const>, and <rc>. These formats and their use are described in detail in 
chapter 6. 


4.1.3 Boundary Condition Types Available For Walls 


Various wall boundary conditions are described in this section. These include head, flow, 
general head, and no flow boundary conditions. 


CHAPTER 4. BOUNDARY CONDITIONS 165 


4.1.3.1 No Flow BC For Walls <noflow> 


No flow boundary conditions prevent default 2-D overland and/or groundwater flow water 
movers from becoming effective. In other words, they remove the default water movers so 
there is no flow through a wall unless the user creates a replacement water mover. The no 
flow boundary conditions must be placed after the creation of overland flow and groundwater 
flow objects, but before adding user created flow objects since the addition of a <noflow> 
water mover removes existing water movers for the wall. The <noflow> element has an 
attribute section with a value section="01" to block overland flow, section="gw" 
to block groundwater flow, or section ="ol_gw" to block both overland and groundwater 
flow. This XML structure is specified in Table 4.3 and demonstrated below and in Table 4.4 
and Figure 4.1 where the overland flow through the walls defined by nodes 2, 6 and 11 is 
blocked. 


<mesh_bc> 
<noflow section="o0l"> 
<nodelist> 2 6 11 </nodelist> 
</noflow> 
</mesh_bec> 


4.1.3.2 Head BC For Walls <wal lhead> 


The head on a model domain boundary can be specified using a wall head <wallhead> 
boundary condition. The head at the wall is specified as a constant or a time variable value 
as indicated in Table 4.4 and Equation 4.1. The head may be applied to groundwater flow, 
overland flow, or both. 

This type of BC makes the most sense when only one wall of a cell is subjected to the BC. 
In the example in Table 4.4 and below, the heads for both overland and groundwater flow 
are specified at walls defined by pairs of nodes 1 — 2, 2—3, 3—4, and 8— 12 with the head at 
each wall determined by linear interpolation between a time series at wall 1-2 and a constant 
value at wall 8 — 12. 





Hi; = Hpg(t) (4.1) 
<mesh_bc> 
<wallhead section="o0l_gw" label="STA-3"> 
<walllist> 12 2 3 3 4 8 12 </walllist> 


<endpts> 
<entry id="1" 
<dss file="headbc.dss" 
pn="/HSE/T C03/HEAD/01JAN1994/15MIN/CALC/"> </dss> 
</entry> 
<entry id="2"> 
<const value="13.6"> </const> 
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</entry> 
</endpts> 
</wallhead> 
</mesh_bc> 


4.1.3.3 General Head BC For Walls <wallghb> 


The wall general head boundary <wallghb> is similar to the wall head boundary. This 
boundary condition specifies a constant or time series head. If the specified head is not equal 
to the head in the cell adjacent to the wall, water flows through the wall to or from the cell 
as computed in Equation 4.2 


(Kelu) 


Kolat + KpLy 





Q(t) — (Hp = H;) (4.2) 





where 
H; = head in the cell, 
Hp = specified boundary condition head. 
Kpg = a user input coefficient that controls the rate of flow through the wall. 
K, = conveyance in the cell. 
K, = transmissivity in the cell. 
Ly = length of the wall forming the boundary of the cell. 
Ly = characteristic flow length. 


Only one general head BC should be applied per cell, because it essentially modifies the 
source term. It can be applied only to walls on the boundary of the model domain. 


In the XML example in Table 4.4 and the example below, a wall general head boundary 
condition is applied to walls defined by the <nodelist> 9131415 16. The flow coefficient 
in Equation 4.2 is 0.064. The specified head is interpolated according to the specified weights 
between two time series in DSS files. 


<mesh_bc> 
<wallghb value="0.064"> 
<nodelist> 9 13 14 15 16 </nodelist> 
<wts2pts> 
<entry id="3"> 
<dss file="Loc1GHB.dss" 
pn="/Loc1//Head/02FEB1994/15MIN//"> </dss> 
</entry> 
<entry id="4"> 
<dss file="Loc2.dss" 
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pn = "/AvgHead/Loc2/Stage/05AMR1993/1DAY/normal/ dbintl="1440" > 
</dss> 
</entry> 
<wts> 1.0 0.2 0.8 0.0 </wts> 
</wts2pts> 


</wallghb> 
</mesh_be> 


4.1.3.4 Uniform Flow BC For Walls <wal luf> 


A uniform flow boundary is defined by assuming that there is uniform overland flow that 
discharges water through the boundary wall. It can be defined by specifying a slope of Sz 
at the boundary cell, with a resulting flow of Qg as in Equation 4.3. 


Qg = KiSp (4.3) 


where K; is the conveyance of the cell. A positive slope yields a uniform flow into the 
cell from beyond the boundary and a negative slope yields flow from the cell across the 
boundary out of the model domain. If the cell becomes dry, there will be no flow. An 
example of XML input for uniform flow is shown below and included as the last boundary 
condition in Table 4.4 which specifies a uniform flow out of the cell bordered by wall 12 — 16 
with a slope of -0.12. 


<mesh_bc> 
<walluf value="-0.12"> 
<nodelist> 12 16 </nodelist> 
</walluf> 
</mesh_bec> 





4.1.4 Boundary Condition Types For Cells 


Various cell boundary conditions are described in this section. These include, flow, head and 
general head options. 


4.1.4.1 Inflow BC <wel1> 


A commonly used upstream boundary condition is an inflow boundary condition defined as 


Qi = Qa(t) (4.4) 


where 
i represents the cell ID, and 
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Q(t) = constant value or a time series of flow. 

Inflow into the model is generally described using the inflow boundary condition. More than 
one of these boundary conditions can be applied at any water body. When this happens, the 
flow is considered additive. This boundary condition may also be used to define a constant 
or time series of flow out of a cell, although this application must be used with care and a 
clear understanding of the physical process being represented. 

The attributes and subelements of <we11> are defined in Table 4.1. An example of a time 
series of pumping rates into cell 3 is demonstrated below, in Table 4.4, and Figure 4.1. The 
flow is defined by a time series in a dss format. 


<mesh_bc> 
<well cellid="3" wellid="7658" label="Pump Station 8"> 








<dss file="Pump8.dss" pn = "/NormalRules/Pump8/Flow/05AMR1993/1DAY/normal/" 
mult="0.02831685" dbintl="1440"> 
</dss> 
</well> 


</mesh_bc> 


The default data type from the file Pump8.dat is INST-VAL or flow. The user has 
the option to specify a volume by specifying the data type PER-CUM as in the following 
example. In this example 1000 units of volume is distributed uniformly over each month. 
The entry dbintl=” 43200” indicates a monthly value and the model adjusts for the number 
of days in each month to achieve a uniform distribution. The model determines the volume 
to be applied in each time step and converts this to a rate. 


<mesh_bc> 
<well cellid="3" wellid="7658" label="Pump Station 8"> 
<const value="1000 type="PER-CUM" dbint1l="43200"\> 
</well> 
</mesh_bc> 











4.1.4.2 Head Boundary Conditions For Cells <cel lhead> 


This boundary condition forces the cell to the specified head at each model time step where 
the head may be a constant or specified by a time series. The elements and attributes 
required to specify this boundary condition are listed in Table 4.1. This boundary condition 
should be used only if there is no other choice, and then only with a clear understanding of 
the implications. Physically there may be a net flow of water to or from the cell without 
the water level in the cell changing. Computationally, if the head at cell n is specified, the 
corresponding row in the solution matrix is set to zero except for the diagonal element which 
is set equal to 1.0. In addition the corresponding entry in the source vector is set equal to the 
difference between the specified head and the present head in the cell. Both physically and 
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computationally, this has the effect of adding or subtracting water from the model domain 
without accounting for it. The water budget, therefore, will be incorrectly computed. The 
XML input below and in Table 4.4 specifies that the head in cell 7 is varied according to the 
values generated by rating curve 12. 


<mesh_bc> 
<cellhead id="7" bcid="42" label="Long Pond"> 
<rce id="12> </rce> 
</cellhead> 
</mesh_bc> 











4.1.4.3 General Head Boundary Conditions For Cells <cel1lghb> 








The general head BC for a cell is similar to the <cellhead> boundary condition but it 
preserves the accuracy of the water budget. A constant or time series head is specified along 
with a constant that controls the rate at which water flows into or out of the cell to approach 
the specified head. The flow is calculated as 





Qi = Kp(Ha(t) — Ai) (4.5) 


where 

Qi = the discharge into the cell, 

H; = head in the cell 2, 

H(t) = head specified by the boundary condition, and 

Kpg = a constant that controls the flow into or out of the cell as defined by the <cellghb> 
attribute <value>. 


The flow computed by Equation 4.5 is added to or subtracted from an imaginary water 
body that holds all boundary condition flows except <cellhead>. This water body is 
included in the water budget calculations. An example of the XML input for a <cellghb> 
boundary condition is shown below and included in Table 4.4. In this example water flows 
into or out of cell 4 at a rate determined by the current head in the cell, the coefficient 
” value” =0.15, and the head specified by the time series in the file PondHead.dss. 


<mesh_bc> 











<cellghb id="4" value="0.15" label="Lake Isabel"> 
<dss file="PondHead.dss" pn = "/AvgHead/Pond2/Stage/05AMR1993/1DAY/normal/ 
"dbintl="1440" label="Head maintained in irrigation pond 3A" > 
</dss> 

</cellghb> 


</mesh_bc> 
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4.2 Boundary Conditions for the Canal Network <network_bc> 


As in the case of overland flow, solution of the canal flow equations depends on the initial 
and boundary conditions, in addition to the governing equation itself. In contrast to the 
flow solution described by the full St. Venant equations, only one boundary condition can 
be applied at each boundary in the case of 1-D diffusion flow. Both head and flow boundary 
conditions are commonly used. They can be applied to canal segments or junctions, however, 
segment head boundary conditions should be avoided to maintain the integrity of water 
budget formulations. 


Flow BC’s are generally applied to segments. The no-flow boundary condition applied 
between two segments is a special case intended to prevent flow between adjacent segments 
when a structure is modeled. Table 4.6 and Table 4.7 below show the elements and attributes 
available for specifying the boundary conditions for canals. Boundary conditions for the 1- 
D canal networks are defined under the <network_bc> element within the <network> 
environment. The boundary conditions specified in the environments <segment source>, 
<segmenthead>, <junctionhead>, and <segmentghb> have flows or heads specified 
by a constant, a time series, or a rating curve under the sub-elements <const>, <dss> and 
<rc>. Details on the use of these options are explained in chapter 6. 


Table 4.6: Elements and Attributes for Specifying Boundary Conditions for Canal Networks Part 1. Element cells are shaded. 



























































<Element> or | Definition Dimen- | Variable Suggested Default Example 

Attribute sions type range 

<segmentsource> | Used to specify the inflow to a segment as a constant or a time series 

id ID of the segment NA Integer 10000-20000 Req. 156324 

bcid Optional BC ID NA Integer >0 -1 23 

label Optional label to identify the BC NA String Any String source-seg+ID Lake 
Kahuna 

<segmenthead> Used to specify the water level at a segment as a constant or a time series. This BC can corrupt the water budgets. 

id ID of the segment NA Integer 10000-20000 Req. 164824 

bcid Optional BC ID NA Integer >0 -1 23 

label Optional label to identify the BC NA String Any String headbc-seg+ID Pond 3B 

<segmentghb> Used to specify the water level at a segment as a general head BC. The head can be a constant, a rating curve, or a 

time series. 

id ID of the segment NA Integer 10000-20000 Req 164824 

kcoeff Coefficient in Equation 4.9 L?T-1 Real > 0.0 Req 0.12 

bcid Optional BC ID NA Integer >0 -1 23 

label Optional label to identify the BC NA String Any String ghb-seg+ID Pond 3B 

<junctionhead> The head at a junction is specified as a constant, rating curve, or a time series. 

id ID of the segment to or from which flow | NA Integer 10000-20000 Req. 164824 

occurs 
beid Optional BC ID NA Integer >0 -1 23 
label Optional label to identify the BC NA String Any String jctheadbc-seg+ID Pond 3B 





























Sub-elements available for specifying the head for the canal bound 





ary conditions <segmentsource>, <segmenthead>, <segmentghb>, 


and <junctionhead> are <const>, <dss>, and <rc>. These are described in detail in chapter 6. NOTE: NA = Not Applicable; Req. = 


Required; 
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Table 4.7: Elements and Attributes for Specifying Boundary Conditions for Canal Networks Part 2. Element cells are shaded. 


<Element> or | Definition Dimensions | Variable Suggested | Default | Example 
Attribute type range 























<uniformflow> Used to specify the canal segment at the end of a network as having uniform flow. Not 
implemented in the current version of the model. 





<junctionblock>| The default water mover between two segments is removed. This is needed if a structure is 
to be placed at the junction. 








id1 ID of the segment on one | NA Integer | 10000-20000 | Req. 164824 
side of the junction 

id2 ID of the segment on the | NA Integer | 10000-20000 | Req. 164824 
other side of the junction 


























NA = Not Applicable; Req. = Required. 
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Sample XML input for all six network boundary conditions under the <network_bc> 
element is shown in Table 4.8 and demonstrated in Figure 4.2. Each available boundary 
condition will be explained in detail in the following sections. 


4.2.1 Flow Boundary Condition <segment source> 


The <segment source> boundary condition is often used at the upstream end of a canal. 
It is similar to the <wel1> boundary condition for a cell. The user may specify an inflow 
or outflow from a canal segment according to the following equation. 


Qi = Qa(t) (4.6) 


Where i represents the segment ID and Qg(t) = a constant, rating curve, or time series 
flow. Methods specifying Q(t) are explained in detail in chapter 6. The XML input 
below excerpted from Table 4.8 specifies a flow into segment 1 defined by a time series 
in the file ”DevilFlow.dss”. The boundary condition may also be specified as a volume 
using the data type PER-CUM as described for the <we11> boundary condition for cells in 
subsubsection 4.1.4.1. The application of this BC is shown graphically in Figure 4.2. The 
multiplier 0.0283 converts the input from cfs to m?/sec. This boundary condition may also 
be used to specify an outflow from a segment by a time series of negative numbers in the 
DSS file or by specifying a negative multiplier. 


<network> 
<network_bc> 
<segmentsource id="1" bcid="35" label="Inflow from Dirty Devil River"> 
<dss file="DevilFlow.dss" pn="/HSE/T C03/HEAD/01JAN1994/15MIN/CALC/" 
mult="0.0283" dbintl="15" units="cfs" > 











</dss> 
<segmentsource> 
<network_bc> 
</network> 


4.2.1.1 Head Boundary Condition <segmenthead> 


The <segmenthead> boundary condition is similar to the <cellhead> boundary condi- 
tion for the 2D mesh. This boundary condition type can be used to specify the water level 
in a canal segment at the model domain boundary. An example would be as an upstream 
boundary condition for a canal that drains water from a large lake. The head in the canal 
segment is specified as shown in Equation 4.7. 


H; = Hp(t) (4.7) 





CHAPTER 4. BOUNDARY CONDITIONS 174 


Table 4.8: Example XML input canal network boundary conditions. 





<network> 
<network_bc> 
<segmentsource id="1" bcid="35" label="Inflow from Dirty Devil River"> 
<dss file="DevilFlow.dss" 
pn="/HSE/T C03/HEAD/01JAN1994/15MIN/CALC/" 
mult="0.0283" units="cfs" > 








</dss> 
<segmentsource> 
</segmenthead id="11" bcid="22" label="Big Lake"> 
<dss file="BigLhLake.dss" 
pn = "/Southshore/BigLake/STAGE/01JAN1996/1DAY/normal/" 
mult="1.0" dbintl="1440">"> 
</dss> 
</segmenthead> 
<junctionhead id="5" bcid="7" label="Downstream Tide"> 
<rce id="17"> 
</rc> 
</junction> 
<segmentghb id="4" kcoef="0.045" bcid="11" label="Lake Lola"> 
<dss file="Lola.dss" 
pn = "/AvgHead/Lola/Stage/05AMR1993/1DAY/normal/ "dbintl="1440" > 
</dss> 
</segmentghb> 
<junctionblock idl="9" id2="10" label="Highway 66 culvert"> 
</junctionblock> 
</network_bc> 
</network> 
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where H(t) can be a time series, a constant, or a rating curve. As with the <cellhead> 
boundary condition, <segmenthead> can introduce errors in the water budget calculations. 
This boundary condition type modifies the solution matrix by setting all entries in the row 
corresponding to the segment number equal to 0.0 except for the diagonal term which is 
set equal to 1.0. The corresponding entry in the source vector is set equal to the difference 
between specified and existing head in the segment. This allows water to flow into or out 
of the segment subject to the head boundary condition without changing the volume of 
water in the segment. If possible, use the <segment ghb> or <junctionhead> boundary 
condition instead, as they preserve the water budget. In the example below, the head in a 
segment is set equal to a time series of water levels in a large lake that drains into the canal. 


<network_bc> 
</segmenthead id="11" bcid="22" label="Big Lake"> 








<dss file="BigLake.dss" pn = "/Southshore/Bighake/STAGE/01JAN1996/1DAY/normal/" 
mult="1.0" dbintl="1440">"> 
</dss> 
</segmenthead> 


</network_bec> 


4.2.1.2 Installing A No-Flow Boundary Condition At Canal Junctions < junct ionblock> 


If two canal segments are adjacent such as segments 10 and 11 in Figure 4.2 a default 
water mover is constructed during the network set up to move water between the seg- 
ments. In the case that this flow is physically replaced by a structure such as a culvert 
under a road that intersects the canal, it is necessary to remove the default water mover 
before replacing it with a user created water mover as described in subsection 3.5.3. The 
<junctionblock> boundary condition removes any existing water movers between the 
segments and prevents flow unless another water mover is created. The example below 
shows the use of the <junctionblock> boundary condition to remove the default water 
mover where a highway crosses the canal. 


<network_bc> 
<junctionblock id1l="10" id2="11" label="Highway 66 culvert"> 
</junctionblock> 


<network_bc> 


4.2.1.3 Uniform Flow In A Segment <uniformflow> 


This boundary condition is not implemented in the current version of the model. 
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A common boundary condition for simulating flow in a river or canal is that of uniform 
flow at the downstream end. This is common practice in modeling backwater profiles with 
models such as HEC-RAS. Uniform flow is computed as a function of the canal geometry, 
roughness, and slope. The general expression for uniform flow is 


OH 
= 4, 
Ox So a) 


where So is the uniform flow slope assigned to the segment. 


4.2.1.4 General Head Boundary Condition In A Segment <segment ghb> 


This boundary condition is similar to the mesh boundary condition <cellghb>. It specifies 
a head as a constant, time series or a rating curve. Water flows into or out of the segment 
in a way as to tend toward the specified head according to the equation; 


Q(t) = Kg(Hg(t) — Aj) (4.9) 


where 

Kpg = a user specified coefficient, 
H(t) = the specified head, and 

H; = the head in the target segment. 


The following example specifies a general head condition in segment 4 with the specified 
head as a time series in the file Lola.dss. 


<network> 
<network_bc> 
<segmentghb id="4" kcoef="0.045" bcid="11" label="Lake Lola"> 





<dss file="Lola.dss" pn = "/AvgHead/Lola/Stage/05AMR1993/1DAY/normal/ "dbint1l="14 


</dss> 
</segmentghb> 
</network_bc> 
</network> 


4.2.1.5 Junction Head Boundary Condition <junct ionhead> 


The <junctionhead> boundary condition is a method for specifying the head at a junction 
adjacent to a canal segment. The flow into or out of the segment from or to an imaginary 
waterbody outside the model domain is given by Equation 4.10. 
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Q= A poe (Hp — H;) (4.10) 
n 


where 

A; = the cross-sectional area of the segment, 

n = the Manning’s roughness coefficient, 

R; = the hydraulic radius, and 

Hpg and H; = the specified boundary head and the head in the designated segment. 


This boundary condition is appropriate for specifying the head at the end of a canal. In 
the example below the flow to or from segment 5 is determined by the canal geometry and 
roughness, and the head difference between the head specified in the file Tide.dat and the 
head in canal segment 5. 


<network> 
<network_bc> 
</segmenthead id="5" bcid="7" label="Downstream Tide"> 
<dss file="Tide.dss" pn = "/Tide/Predicted/Stage/05AMR1993/15MIN/normal/ "dbint1l= 
</dss> 
</segmenthead> 
</network_bc> 
</network> 
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~ <segmentsource> 
"DevilFlow.dss" 


/ <segmenthead> 
= "BigLake.dss" 





2 <uniformflow> / 


11 "slope = 0.006" 
<junctionblock> ` 
"Highway 66 culvert" 
_-~<segmentghb> 
"Lola.dss" 


` <junctionhead> 
"Tide.dss" 


Figure 4.2: Illustration of the application of Canal Network Boundary Conditions. 
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4.3 Boundary Conditions For General Water Bodies 


Some of the same boundary conditions defined for the 2-D mesh or network boundary condi- 
tions can be defined using generic water body boundary conditions. They are more powerful 
because they can be applied equally to cells, segments and lakes. The basic categories are 
listed in Table 4.9 and described in detail in the following sections. Sample XML input for 
these boundary conditions is displayed in Table 4.10. Note that these boundary conditions 
are specified within the <watermover> environment. 


Table 4.9: Elements and Attributes for Specifying Boundary Conditions for General Water Bodies in the <watermover> 
environment. Element cells are shaded. 















































<Element> or | Definition Dimen- Variable Suggested | Default Example 
Attribute sions | type range 
<source> Used to specify the inflow to or outflow from a water body as a constant, a time series, or a 
rating curve. 
id ID of the water body NA Integer | Any valid | Req. 187324 
water body 
ID 
label Optional label to identify the BC | NA String Any string wm-+ID L3 irri- 
gation 
pond 
<hq_relation> | The flow into or out of a water body is determined by a 1D lookup table. 
id ID of the water body NA Integer | 10000-20000 | Req. 164824 
label Optional label to identify the BC | NA String Any string wm-+ID Long Pond 
weir 
wmid Water mover ID NA Integer >0 Req. 23 
mult Multiplier for the 1D lookup val- | NA Real Any real 1.0 0.0328 





ues, often for unit conversion 























<hq> The lookup table is included as text in the <hq> environment. The data are entered as two 
columns with stage in the first column and discharge in the second. 





The <source> element has the following sub-elements available for specifying the flow or head: <const>, 
<dss>, and <rc>. These elements and their attributes are described in detail in chapter 6 








NA = Not Applicable; Req. = Required. 
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Table 4.10: Example XML input for general water body boundary conditions. 





<watermovers> 
<source id="34" label="Walden Pond"> 
<const value="78.0" dbintl="15" mult="0.0283"> </const> 
</source> 
<hq_relation id="2" mult="0.5" label="Pond 3D"> 
<hq> 
40.0 5000.0 
50.0 4000.0 
52:20 10.0 
52.2 0.0 
</hq> 
</hq_relation> 
</watermovers> 











4.3.1 Sources And Sinks <source> 


The <source> boundary condition performs nearly the same operation as the <segment source> 
and <well> boundary conditions, but it can be applied to any water body. Unlike the 
<segmentsource> and <well> boundary conditions, only flow and not volume may be 
specified. The inflow to or outflow from a water body is defined as 


Q = Qa) (4.11) 


where 2 = the water body ID, 
Q(t) = constant, rating curve, or time series flow. 


Methods specifying Qp(t) are explained in detail in chapter 6. In the example in Ta- 
ble 4.10 a constant flow of 78.0 cfs flows into Walden Pond (water body 34) with a database 
interval of 15 minutes. The multiplier of 0.0283 will convert the flow from cfs to m?/sec. 


4.3.2 Boundary Conditions Based On Stage-Discharge Relationships <hg_relation> 


A boundary condition described using a stage-discharge relationship for a water body 7 can 
be expressed mathematically as 

Qi = f( Hi) (4.12) 
where 
Qi = discharge into water body i, 
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H; = stage of water body i, 
f(H;) represents a function of Hj. 


The effect would be an inflow into water body 7 as described by the function. The 
example in Table 4.10 describes inflow into Pond 3D as a function of head in the pond. The 
flow is regulated so as to keep the water level in the pond at about 52 meters with the flow 
rapidly reduced as the water level increases from 50 to 52 meters. 
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4.4 Boundary Conditions For Lakes <1 ake bc> 


Boundary conditions for lakes are defined under the <lake_bc> element in the <lakes> 
environment. There are two boundary conditions available, <lLakesource> and <owet>. 
The elements and attributes are listed in Table 4.11 and described in detail in the following 
sections. Sample XML input for these boundary conditions is displayed in Table 4.12. 






























































Table 4.11: Elements and Attributes for Specifying Boundary Conditions for Lakes. Element cells are shaded. 
<Element> or | Definition Dimen- Variable Suggested Default Example 
Attribute sions | type range 
<lakesource> | Used to specify the inflow to or outflow from a lake as a constant, a time series, or a rating 

curve. 
lakeID ID of the lake NA Integer | Any valid lake | Req. 237345 
ID 

id Boundary condition ID NA Integer | Any integer -1 17 

label Optional label to identify the BC | NA String Any String No default | FPL pump 
4 

<owet> The ET from the surface of a lake is specified as a function of the surface area of the lake. 

lakeID ID of the lake NA Integer | 10000-20000 Req. 254824 

id Boundary Condition ID NA Integer | >0 -1 31 

label Optional label to identify the BC | NA String Any String No default | Measured 
ET 

<sa> A 1D lookup table is included as text in the <sa> environment. The data are entered as 


two columns with stage in the first column and surface area in the second. 





The <lakesource> and <owet> elements have the following sub-elements available for specifying the flow or 
RefET: <const>, <dss>, and <rc>. These elements and their attributes are described in detail in chapter 6 








NA = Not Applicable; Req. = Required. 
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Table 4.12: Example XML input for lake body boundary conditions. 


<lakes> 
<lakesource lakeID="237345" id="17" label="STA17"> 











<dss file="STA17Pump.dss pn="/STA/17/FLOW/08MAR2003/1DAY// </dss> 
</lakesource> 
<owet LakeID="254824" id="31" label="STA17ET"> 
<sa> 
970 0.0 
10.0 50.0 
15.0: 10050 
25:0 , -50070 
</sa> 
<dss file="STA17Evap.dss pn="/STA/17/FLOW/08MAR2003/1DAY// </dss> 
</owet> 
</lakes> 


4.4.1 Sources And Sinks <lakesource> 


The <lakesource> boundary condition performs the same operation as the <well>, 
<source>, and <segmentsource> boundary conditions, but it can be applied only to 
lakes. The inflow to or outflow from a lake is defined as 


Qi = Qoli) (4.13) 


where 
i = represents the lake ID, and 
Q(t) = constant, rating curve, or time series flow. 


Methods specifying Q(t) are explained in detail in chapter 6. In the example in Ta- 
ble 4.12 a time series flow specified in STA17Pump.dss flows into STA17 (lake id = 237345) 
with a database interval of 1 day. 


4.4.2 Open Water Evaporation Boundary Condition <owet> 


This boundary condition removes water from a lake according to the equation 
Qi = Area(H;)Ref ET (t) (4.14) 


where 
Qi = evaporation rate from the lake 2, 
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H; = water level in the lake i, 
Area(H;) = the lake surface area interpolated from a 1D lookup table, and 
Ref ET(t) is the potential evaporation defined as a constant, a rating curve, or a time series. 


The example in Table 4.12 describes evaporation from lake STA17 as a function of head 
in the lake and the specified RefET. The surface area of the lake is read from the 1D lookup 
table <sa> with the area increasing from 0 to 500 as the head increases from 5.0 to 25.0 
meters. RefEt is specified as a time series in the file STA17Evap.dss. 


Chapter 5 


Hydrologic Process Module Approach and 
Models 


HPMs provide a method to simulate the local surface hydrology in a mesh cell or a collection 
of mesh cells. The mesh cells are used in the implicit finite volume solution for the regional 
flow while the HPMs explicitly simulate the local hydrology before the next time step of the 
implicit regional solution. HPM types available are designed to simulate 


ji 


. Unsaturated flow in soil 

. Interception and detention of flow 

. Interflow, field drainage 

. Urban hydrology and related management practices 
. Rainfall-Runoff simulation 

. Agricultural irrigation and drainage practices 

. Everglades ridge and slough hydrology 


. Small creek and tributary flow 


Oo Oo nN Q om A CWO N 


. Discharge, seepage and aquifer recharge from detention and retention ponds 


5.1 HPM Types 


The area simulated by the RSM may include native lands as well as developed land, both 
urban and agricultural. The natural areas are represented by hydrologic processes only 
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slightly impacted by human activities. These include much of the everglades and other 
swamps and protected upland areas. Large parts of the model domain such as the EAA, 
South Dade County, and the Caloosahatchie basin are predominantly agricultural with in- 
tensive cultivation and water management including irrigation. Agricultural areas include 
constructed drainage ditches to capture field drainage and impoundments to hold water and 
release it at a controlled rate. Other regions, particularly along Florida’s east coast, are 
highly urbanized with large areas of impervious surfaces, constructed drainage systems, and 
retention/detention ponds. The HPMs currently in the RSM have been designed to simulate 
each of these types of areas. There is also a HPM that does nothing that is useful for turning 
off hydrologic processes in selected areas for model testing and development. 


In the following discussion, HPM descriptions will be broadly classified into these three 
general types. The term in brackets such as <layerinsm> is the XML element that creates 
the environment for specifying the attributes of the HPM. 


1. Natural System HPMs 
Natural Wetland System <layerlnsm> 
No Action <layerpc> 
Precipitation Runoff Routing <prr> 
Five Unsaturated Soil Layer <layer5> 


Unsaturated Soil <unsat> 


2. Agricultural HPMs 
Agricultural Irrigation Requirements <afsirs> 
Drainage Collector Ditch <pumpedditch> 


Agricultural Impoundment <agimp> 


3. Urban HPMs 
Multi-Basin Routing <mbrcell> 
Impervious Land <imperv> 
Urban Detention <urbandet> 


Consumptive Use <cu> 
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5.2 Natural System HPMs 


The natural system HPMs that are designed to simulate local hydrology in relatively undis- 
turbed areas can be grouped by hydrologic processes into two distinct groups of land uses, 
wetlands and uplands. The principal distinction is the interaction with the surficial aquifer. 
In wetlands and other areas where the water table is in the root zone for most of the year, 
the local hydrology is largely controlled by the depth to the water table. In upland areas 
there is substantial water storage in the unsaturated zone above the water table but below 
the root zone. This water will drain from the soil over extended periods contributing to 
surface water and regional groundwater. These natural areas differ from developed areas in 
that the hydrology is controlled by the native landscape features and water moves slowly 
through the landscape. The natural systems HPMs are briefly described below: 


1. The <layerinsm> HPM type is used to represent the local hydrology for wetlands 
and high water table soils. This HPM works well where the water table is in the root 
zone for extended periods of the year. The available soil water for evapotranspiration 
is determined by the location of the water table. When the water table is below 
the root zone the simple algorithm used in this model does not accurately describe 
evapotranspiration and the water budget is not accurately simulated. 


2. The <mbrcell> HPM was developed as a simple runoff model that combines the 
NRCS curve number runoff algorithm with simple linear reservoir routing. 


3. The <unsat> HPM is an extension of the layerlnsm HPM type. Whereas the layerlnsm 
assumes that there is no unsaturated soil and all of the water for evapotranspiration 
is extracted from the water table, unsat maintains moisture accounting in the un- 
saturated zone as well as tracking the water table. The available moisture in the 
unsaturated zone is extracted for evapotranspiration demand before water is removed 
from the water table. 


4. The <layer5> HPM is an extension of the unsat HPM. The layers HPM is composed 
of 2 water layers above the ground surface, the shallow root zone, the deep root zone, 
and the deep soil layer. <layer5> tracks the unsaturated zone soil moisture and 
water table. In addition, the <layer5> HPM has the capability of modeling the soil 
moisture of multiple soil horizons as would occur in a typical soil profile. 


5. The <layerpc> HPM performs no calculations and uses none of the HPM access 
functions. It is used as a place-holder when the simulation of local hydrology is not 
desired. This may occur during the calibration process to test limited sections of the 
model domain; either to conduct testing of HPMs in a limited area or testing of other 
model components without HPMs. It may also be used with lower layer cells in a three 
dimensional groundwater simulation to maintain mass balance. 
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5.2.1 Natural Wetland System <1 ayerinsm> 


This HPM was introduced to satisfy the need to simulate natural hydrology in natural system 
models. This HPM calculates a simple water budget for the soil with a water table that is 
defined by the water level in the mesh cell. Hydrologic processes that occur in this HPM are 
shown in Figure 5.1. 























Rain Evap ET ~Ke 
Z + Pd 
Ground Surface (Z) Z KEY a 
a ET = Evapotranspiration 
Infiltration Evap = Evaporation 
Z - Rd ++ — Ke = ET Crop Correction Coefficient 
Kveg = Root Zone ET Coefficient 
Pseudocell Inflow Kw = Open Water ET Coefficient 
Watertable (mesh cell) Z- Xd Pd = Ponding Depth 


Rd = Shallow Root Depth 
Xd = Extinction Depth 
Z = Ground Surface 





Figure 5.1: HPM Components of Water Budget for the <layerlnsm> HPM. The variation of 
the Reference ET Crop Coefficient as a function of input parameters is also shown. 


Table 5.1: Elements and Attributes for the <layerlnsm> HPM. Element cells are shaded. 





























<Element> or | Definition Dimensions | Variable Suggested Default | Example 

Attribute type range 

<layerinsm> | Designates the NSM type HPM 

kw Maximum crop coefficient for | NA Real 0-1 Req 1.0 
open water 

rd Shallow root zone depth (m) L Real 0-10 Req 2.6 

xd Extinction depth below which | L Real 0-10 Req 5.6 
no ET occurs (m) 

pd Open Water ponding depth | L Real 0-2 Req. 1.3 
(m) 

kveg Vegetation crop coefficient NA Real 0-1 Req 0.7 

fld_cap Water content at field capacity | L Real 0.0 - 0.5 0.0 0.32 
(m) 

imax Maximum Interception (m) L Real 0-1 0.0 0.15 


























NA = Not Applicable; Req. = Required. 
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Table 5.2: Example XML input for a <layerinsm> HPM. 





<pseudocell> 
<indexed file="lu.index"> 


<entry id="2"> 
<layerinsm kw="1.0" rd="0.5" xd="2.0" pd="3.0" kveg="0.75" imax="0.0"> 
</layerlnsm> 

</entry> 


</indexed> 
<\pseudocell> 











The XML elements and attributes used to describe a <layerlnsm> HPM are described 
in Table 5.1. An example of the XML input for a <layerinsm> HPM is shown in Table 5.2. 
lu.index is an index file that assigns a HPM identified by its <entry> id to each mesh cell. 


5.2.2 Three Dimensional Groundwater Cell HPM <layerpc> 


The <layerpc> HPM simulates no hydrologic processes and requires no attributes in the 
XML input. When simulating three dimensional flow under both confined and unconfined 
conditions there is no need to carry out hydrologic functions, but there is a need to maintain 
mass balance. This HPM acts as a placeholder for this function in a three dimensional 
groundwater simulation. A sample XML input for a <layerpc> HPM is shown Table 5.3. 
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Table 5.3: Example XML input for a <layerpc> HPM. 





<pseudocell> 
<indexed file="lu.index"> 


<entry id="2"> 
<layerpe> </layerpc> 
</entry> 


</indexed> 
<\pseudocell> 











5.2.3 Multi-Basin Routing HPM <mbrcel1> 


The MBRceell was created to provide a simple HPM for modeling runoff and routing. Much 
of the runoff occurs before the soil is fully saturated. To simulate this behavior the runoff 
approach in the <mbrcel1> is similar to the NRCS curve number method for calculating 
the volume of runoff. The runoff volume is routed through a linear reservoir to control the 
hydrograph timing. 


Table 5.4: Elements, attributes, and typical values used for the <mbrcell> HPM. 


























<Element> or | Definition Dimensions | Variable Suggested Default | Example 

Attribute type range 

<mbrcell> Designates the mbrcell type HPM 

route wb ID for destination of dis- | NA Integer | Any valid wb | Req 7 
charge ID 

tc Time of concentration (s) T Integer | 900 - 50,000 | Req 3600 

kveg Evapotranspiration crop coef- | NA Real 0.0 1.0 Req 0.85 
ficient 

d_shal Shallow root zone depth (m) | L Real 0.5 - 3.0 Req 2.0 

d_deep Deep root zone depth (m) L Real 1.0 - 5.0 Req 3.5 

fld_cap Water content at field capac- | L Real 0.0 - 2.0 Req 0.2 





ity (m) 























NA = Not Applicable; Req. = Required. 








STHGCOW ANV HOVOUddV ATAGOW SSHOOUd OIDOTOUGAH S YHLdVHO 


pOT 


CHAPTER 5. HYDROLOGIC PROCESS MODULE APPROACH AND MODELS 195 


Table 5.5: Example XML for an <mbr> HPM. 





<pseudocell> 
<indexed file="lu.index"> 


<entry id="5"> 
<mbrcell route="7" tc="3600.0" kveg="1.0" d_deep="2.0" 
d_shal="0.5" fld_cap="0.2" 
</mbrcell> 
</entry> 


</indexed> 
</pseudocell> 











The elements and attributes used in defining an <mbrcell> HPM are shown in Ta- 
ble 5.4. A simple example of the MBRcell HPM is presented in Table 5.5. 
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5.2.4 Five Soil Layer HPM <layer5> 


The <layer5> HPM shown in Figure 5.2 simulates the water budget in a layered unsatu- 
rated soil with rainfall and potential evapotranspiration as meteorological input. The soil is 
divided into three layers. The other two layers are ponded layers above ground level with 
the lower layer being in the vegetated zone and the top layer above the elevation at which 
open water occurs. Ke decreases from Kw in the open water layer to Kveg in the vegetated 
zone and the shallow root zone, and then decreases linearly to zero at the bottom of the 
deep root zone. 


The elements and attributes used to define a <layer5> HPM are described in Table 5.6. 
The extractable water is a depth of water equivalent to field capacity minus wilting point. 
The gravitational water which is equal to saturation minus field capacity is equivalent to the 
specific yield. The specific yield is obtained from the properties of the mesh cell to which 
the HPM is attached. 


An example of the XML input for the layers HPM is provided in Table 5.7 and in 
Benchmark 18. 


Rain ET 


Soil Layer 





Ponded 
Z+Pd f 


Flooded 


Shallow 
Root Zone KEY 





ET = Evapotranspiration 

Deep Kc = ET Crop Correction Coefficient 
Root Zone Kveg = Root Zone ET Coefficient 
Kw = Open Water ET Coefficient 
Pd = Ponding Depth 

| Extinction Rd = Shallow Root Depth 

Zone Xd = Extinction Depth 

Z = Ground Surface 


Z - Xd 

















=—Ke 
0 Kveg Kw 


Figure 5.2: Soil layers modeled in the <layer5> HPM and the variation of the ET coefficient, 
Ke with water table. 


Table 5.6: Elements and Attributes for the <layer5> HPM. 


























<Element> | Definition Dimensions| Variable Suggested | Default | Example 

or Attribute type range 

<layer5> Designates the layer5 type HPM 

ew Extractable water L Real 0.0 - 0.5 Req 0.2 

kw Maximum crop coefficient for | NA Real 0.5 - 1.2 Req 1.0 
open water 

rd Shallow root zone depth, (m) | L Real 0.2 - 2.0 Req 1.0 

xd Extinction depth below which | L Real 1.0 - 10.0 Req 3.0 
here is no ET, (m) 

pd Ponding depth, (m) L Real 0.0 - 2.0 Req 1.0 

kveg Vegetation crop coefficient NA Real 0.0 - 1.0 Req 0.85 


























NA = Not Applicable; Req. = Required. 
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Table 5.7: Example XML for <layer5> implementation. 





<pseudocell> 
<indexed file="lu.index"> 
<entry id="1"> 
<unsat ew="0.2" kw="1.0" rd="0.5" xthresh="0.02" 
pthresh="0.10" pd="3.0" kveg="0.75"> 
</unsat> 
</entry> 
<entry id="2"> 
<layer5 ew="0.2" kw="1.0" rd="2.0" xd="5.0" pd="3.0" kveg="0.5"> 
</layer5> 
</entry> 
<entry id="3"> 
<layer5 ew="0.2" kw="1.0" rd="0.0" xd="0.5" pd="3.0" kveg="0.65"> 
</layer5> 
</entry> 
</indexed> 
</HPM> 











5.2.5 Unsaturated Soil HPM <unsat> 


The Unsat HPM computes a simple water budget for a single-layer soil, Figure 5.3. This 
HPM is similar to the <layerlnsm> HPM except it considers water in the unsaturated 
soil above the water table in the water balance accounting whereas <layer1nsm> does not. 
Since the water budget accounts for the water content of the unsaturated zone, this can be a 
useful option to use in areas where the water table may be well below ground for a significant 
portion of the year. 


The elements and attributes used to describe the Unsat HPM are presented in Table 5.9. 
The specific yield is determined by the soil properties of the underlying mesh cell. 


CHAPTER 5. HYDROLOGIC PROCESS MODULE APPROACH AND MODELS 199 


Rain ET 


Cell Delta 


Unsaturated 


PsInflow 


Watertable 
(mesh cell) 





Figure 5.3: Schematic water budget for <unsat> HPM. 


Table 5.8: Water table location, available water content and crop coefficient values for <unsat> 
HPMs. 




















Watertable Available water content | Reference Crop ET Correction Coefficient (Kc) 
> Pd Ponded water Kw 

> Land surface and < Pd | Flooding Pwd/pd x (Kw - Kveg)+ Kveg 

< Land surface > Pthres Kveg 

< Land surface Xthres < © < Pthres (© — Xthres)/ (Pthres — Xthres) * Kveg 

< Land surface < Xthres 0 














The parameters above are defined in Table 5.9 








Table 5.9: Elements and attributes for the <unsat> HPM. 


















































<Element> | Definition Dimen- Variable Suggested Default | Example 

or Attribute sions | type range 

<unsat> Designates the unsaturated type HPM 

ew Extractable water (m) L Real 0.0 - 1.0 Req 0.2 

kw Maximum crop coefficient for water NA Real 0.5 - 1.0 Req. 1.0 

rd Root zone depth, (m) L Real 0.0 - 2.0 Req. 0.5 

wilt Soil water content at wilting point (m) | L Real 0.0 - 0.1 Req 0.02 

pd Ponding depth (m) above which open | L Real 0.0 - 2.0 Req 1.0 
water occurs 

xthresh Soil water content when ET ceases (m) | L Real 0.0 - 0.3 Req. 0.1 

pthresh Soil water content (m) when Kc begins | L Real 0.0 - 0.5 Req. 0.22 
to decrease from Kveg to 0 

kveg Vegetation crop coefficient NA Real 0.5 - 1.0 Req 0.75 








NA = Not Applicable; Req. = Required. 
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Table 5.10: Example XML for an <unsat< HPM. 





<HPM> 
<indexed file="lu.index"> 
<entry id="1"> 
<unsat ew="0.2" wilt="0.03" kw="1.0" rd="0.5" xthresh="0.02" 
pthresh="0.10" pd="3.0" kveg="0.75"> 
</unsat> 
</entry> 


</indexed> 
</HPM> 











An example of XML input for an Unsat HPM is presented in benchmark BM18 and in 
Table 5.10. 
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5.3 Urban HPMs 


The key characteristic of simple urban HPMs is the amount of impervious land that results 
in greater runoff and reduces the amount of evapotranspiration. The simplest urban HPM 
is for impervious land. It is possible to represent a fraction of of the urban land as turf 
grass representing lawns and landscaping, and model that land using afsirs. Urban land 
can also be modeled using the precipitation-runoff routing HPM which can be calibrated for 
stormwater detention and routing. The two simple HPMs designed for simulation of urban 
areas are 


1. The <imperv> HPM simulates impervious areas with rainfall, ET, surface storage 
and runoff. There is no recharge to the underlying soil. 


2. The <prr> HPM isa deterministic lumped parameter conceptual model with moderate 
input data requirements. Water is stored in various compartments; interception, upper 
zone and lower zone from where it is apportioned to runoff, groundwater recharge, 
evapotranspiration, and interflow. 


5.3.1 Impervious Area <imperv> 


Specific hydrologic processes occurring on impervious areas include rainfall, evaporation, 
interception, surface detention, runoff, and seepage from storm sewers and ditches carrying 
water from the impervious areas to detention ponds or canals. 


If the impervious area is is directly connected, 5 percent of the runoff is lost as seepage 
from storm sewers and drainage ditches. The <imperv> HPM is implemented with the 
elements and attributes shown in Table 5.11 and an example of xml input to implement an 
<imperv> HPM is presented in Table 5.12 


Table 5.11: Elements and attributes for the <imperv> HPM. 





























<Element> or | Definition Dimen- Variable Suggested Default | Example 

Attribute sions | type range 

<imperv> Designates the <imperv> HPM 

dirconn Specifies directly or indirectly | NA Integer | 0=DCIA, 0 1 
connected 1=UCIA 

isto Maximum interception stor- | L Real 0.001 - 0.1 Req 0.03 
age depth, (m) 

istol Initial interception storage | L Real 0.001 = 0.1 0.0 0.02 
depth, (m) 

sdet Maximum depressional sur- | L Real 0.01 = 0 Req 0.08 
face storage depth, (m) 

sdet1 Initial depressional surface | L Real 0.01 = 0 0.0 0.05 





storage depth, (m) 


























NA = Not Applicable; Req. = Required. 
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Table 5.12: Example xml for the <imperv> HPM. 





<pseudocell> 
<indexed file="lu.index"> 

















<entry id="2" label="connected impervious"> 
<imperv sdet="0.15" isto="0.01" dirconn="1"></imperv> 
</entry> 
<entry id="3" label="unconnected impervious"> 
<imperv sdet="0.05" isto="0.01"></imperv> 
</entry> 
</indexed> 
</pseudocell> 











5.3.2 Precipitation-Runoff Routing HPM<prr> 


In the model (Figure 5.4), water is stored as interception storage and in an upper storage 
zone denoted by U and a lower storage zone denoted by L. The meteorological input data 
are precipitation, and potential evapotranspiration. On this basis, it produces catchment 
runoff, and groundwater recharge. The resulting catchment runoff is split conceptually into 
overland flow, interflow and baseflow components. 


5.3.2.1 Input Data 


The data needed for the <prr> HPM are defined in Table 5.13. The simplified version of 
PRR contains nine parameters to be determined by calibration. Some of the less important 
parameters can be set to default values. In particular, TOF, TIF, and TG can often be 
set to zero. An example of XML input for a <prr> HPM is shown in Table 5.14 and in 
Benchmark 56. 
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KEY 


ET - Evapotranspiration 

Pn - Excess Rainfall 

QOF - Overland Flow 

ROF - Routed Overland Flow 
QIF - Interflow 

Infil - Infiltration 

L - Lower Zone Moisture 

U - Upper Zone Moisture 

| - Interception Moisture 

G - Groundwater Recharge 
RG - Routed Groundwater Recharge 


= Linear Reservoir Router 





QIF 





Figure 5.4: Conceptual diagram of the <prr> HPM. 


Table 5.13: Definition of attributes of the <prr> HPM 















































<Element> | Definition Dimensions Variable] Suggested | Default | Example 

or Attribute type range 

<pre> Designates the PRR type HPM 

etcoef ET crop coefficient NA Real 0.0-1.0 Req. 0.8 

kOinf Maximum infiltration rate, m/s LP Real 0.0-1.0 Req. 0.4 

imax Maximum interception storage, m | L Real 0.0-1.0 Req 0.05 

umax Maximum upper zone moisture | L Real 0.0-1.0 Req 0.5 
content, m 

Imax Maximum lower zone moisture | L Real 0.0-2.0 Req. 1.3 
content, m 

tof Threshold value of lower zone | L Real 0.0-1.0 0 0.3 
storage L for overland flow 

tif Threshold value of lower zone | L Real 0.0-1.0 0 0.3 
storage L for interflow 

tg Threshold value of lower zone | L Real 0.0-1.0 0 0.3 
storage L for groundwater 
recharge 

cqof Overland flow runoff coefficient NA Real 0.0-1.0 0 0.3 

ckol Time constant for overland flow | T Real 0.0-200 Req 47.0 
routing 

ckif Time constant for interflow from | T Real 0.0-2000 Req. 48.3 
the upper zone storage 

ckbf Time constant for groundwater | T Real 0.0-5000 Req. 567.8 





routing 























NA = Not Applicable; Req. = Required. 
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Table 5.14: Example XML code from benchmark 56 for a <prr> HPM. The parameters are 
described in Table 5.13 





<pseudocell> 
<nam etcoef="1.0" kOinf="3.5E-6" umax="0.025" 1lmax="0.27" imax="0.01" 
tof="0.01" cqof="0.50" ckif="480.0" ckol="528." ckbf="2784.0"> 
</nam> 
</pseudocell> 














5.3.2.2 Initial Conditions 


The initial conditions required by the PRR model consist of the initial water contents in the 
surface and root zone storages, together with initial values of storages in the two routing 
reservoirs for overland flow and baseflow. In the current implementation these initial values 
are set equal to zero. In the calibration, it is recommended to disregard the first half year 
or so of the PRR simulation to eliminate the influence of erroneous initial conditions. 
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5.4 Complex HPMs 


The simple HPMs described above are useful for modeling simple landscapes and land use 
types with simple hydrology. In complex landscapes or land use types with highly managed 
local hydrology, it is necessary to use complex HPMs to obtain an appropriate description of 
the hydrology. The principal tool for modeling the complex location hydrology is the hub. 
The hub allows the combination of several HPM types based on areal distribution. The hub 
also allows for the implementation of additional HPM types that handle local routing. 


5.4.1 Water Management Systems <hub> 


Although simple urban and agricultural HPMs can be used to simulate simple, relevant 
features of the landscape, irrigation demand and accelerated runoff, the landscape of South 
Florida is more complex and the local hydrology can be better represented by developing 
water management systems. Water management systems can be represented by the use of 
hubs. Hubs have the capability of linking several HPM types together to model the hydrology 
of urban and agricultural developments. 


The Hub is normally used to model an urban area or a large agricultural operation 
that has a mixture of land uses and a single water source and runoff destination. This is 
appropriate for citrus groves or vegetable farms that withdraw irrigation water from a single 
well or canal and discharge it through a pump or weir to an off-site canal. 


A Hub is appropriate where the composite HPM can be applied uniformly for all cells in 
the hub and the resulting seepage and water use can be applied uniformly. However, where 
the location of the impoundment or pumped ditches is important an agricultural hub and 
an AgImp hub can be linked to obtain the appropriate functionality. 


The elements and attributes required to create a hub are listed in Table 5.15. An example 
xml input showing the creation of a hub with a complex mix of land use types is shown in 
Table 5.16 and Table 5.17. 


Table 5.15: Elements and attributes for the <hub> HPM. 
































<Element> Definition Dimen- | Variable) Suggested range Default | Example 
or Attribute sions type 
<hub> Designates the <hub> HPM 
wsupply Source of the water supply for | NA String "homecell” ”whb-nnn” | homecell | well-342 
the hub *well-nnn” where nnn 
is a water body or well 
ID 
sewer Destination of sewer flow NA String ”homecell” ”whb-nnn” | homecell | wb- 
where nnn is a water- 345654 
body number 
runoff Destination of hub runoff NA String ”homecell” ”wb-nnn” | homecell | homecell 
where nnn is a water- 
body number 
<psentry> Environment for specification of HPMs in the hub 
psID HPM ID NA Integer | 100000-200000 -1 134768 
percentarea Percent of the hub covered by | NA Real 0.0 100.0 100 20.0 
this HPM 
runoff Destination of runoff from | NA String ”homecell” ”hub” ”ps- | homecell | hub 
this HPM nnn” where nnn is a 
HPM ID 
wsupply Source of water supply for this | NA String ”homecell” ”hub” ”ps- | homecell | homecell 





HPM 











nnn” where nnn is a 


HPM ID 











The HPM for this entry <afsirs>, <imperv> etc., is specified in this environment. 











NA = Not Applicable; Req. = Required. 
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The preferred implementation of HPMs will be the utilization of a small number of 
simple HPM types applied throughout the domain, on a one HPM per mesh cell basis. For 
example, all cells with a greatest percent of any land use type within the cell become citrus 
cells. This is appropriate where the source of irrigation comes from the cell and runoff is 
directed to the cell. If each citrus cell requires a specific well or discharges to a specific canal 
segment, it is necessary to have a unique HPM for each mesh cell. Where there are large 
blocks of citrus that use the same well, these can be consolidated into a Hub and that unique 
HPM can be applied to several cells. There are several HPMs that have been developed to 
work within the hub construct. These HPMs interact with other HPMs to provide a better 
representation of the urban and agricultural landscape. These HPMs are listed here and 
described in the following sections. 


1. The <afsirs> is an agricultural irrigation requirements HPM that compute the wa- 
ter budget of agricultural fields. It is customizable for specific crops and irrigation 
schedules and computes drainage from the soil as well as irrigation demands. 


2. The <pumpedditch> HPM simulates a ditch or system of ditches that is maintained 
at a nearly constant water level by pumping. The water budget includes inflow, evap- 
oration, pumping and seepage between the ditch and the aquifer. 


3. The <agimp> HPM simulates an agricultural impoundment constructed to meet local 
environmental requirements. It first computes the size of the impoundment and the 
outlet structure and then routes inflow through the impoundment to a designated water 
body. 


4. Consumptive use<cu> allows the extraction of water from wells for domestic or other 
use and the return of used water through sewers or septic systems. 


5. Retention/detention storage and discharge is modeled using the <urbandet> HPM. 
Water is input from other HPMs and rainfall and leaves through ET, seepage, and 
discharge through the outlet structure. 


5.4.2 Large Agricultural Developments 
5.4.2.1 Agricultural Irrigation Requirement HPM <afsirs> 


The Afsirs HPM is the primary HPM used to estimate irrigation demand and drainage 
from agricultural land. The afsirs HPM was an adaptation of the Agricultural Field-Scale 
Irrigation Requirement System (AFSIRS) model (Smajstrla, 1990). AFSIRS estimates gross 
and net irrigation requirements for selected crop type, soil, irrigation method and irrigation 
management type for a given daily reference crop potential evapotranspiration and rain time 
series. 
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Table 5.16: Example XML for typical complex <hub> containing native, agricultural and urban 
HPM types. 





<pseudocell> 
<indexed file="lu.index"> 


<entry id="5"> 
// define HUB 








<hub runoff="homecell" wsupply="wb-206" sewer="homecell"> 
// Nature systems 
<psentry psID="2" percentarea=" 10.0" runoff="homecell"> 
<layerinsm kw="1.1" rd="2.0000" xd="4.0000" pd="1.8400" veg="0.85"> 
</layerlnsm> 
</psentry> 
<psentry psID="6" percentarea=" 5.0" runoff="homecell"> 
<layerinsm kw="1.1" rd="2.0000" xd="4.0000" pd="1.8400" kveg="0.85"> 
</layerlnsm> 
</psentry> 
// Agricultural Land 
// annual crop - tomato 
<psentry psID="11" label="fall tomato - micro irrigation"> 








<afsirs coupled="no"> 
<afcrop lLabel="tomato" id="60" 31="09-01" jn "12 31" d pthi="9" 
depth2="12"> 

















<kctbl> 
1.05 0.75 0.22 0.30 0.30 0.18 
</kctbl> 
<awdtbl> 
0.40 0.40 0.40 0.65 
</awdtbl> 
</afcrop> 
<afirr label="MICRO, SPRAY" wtd="3.0"> 
<irrmeth id="3" eff="0.8" arzi="0.5" exir="0.4"></irrmeth> 
<irrmgmt trigcode="0"></irrmgmt> 
</afirr> 
<afsoil label="0.8 SOILS" depth="96" minwc=".07" maxwc=".07" cond="1"> 
</afsoil> 
</afsirs> 
</psentry> 


// Urban land 
// Consumptive use 
<psentry> 
<cu label="HI" percentarea=" 100.0" wsupply="hub"> 
<const value=" 0.00221"></const> 
<sewer fracloss="0.1"></sewer> 
</cu> 
</psentry> 
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Table 5.17: Example XML for typical complex <hub> containing native, agricultural and urban 


HPM types (continued). 
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// UrbanDet 
<psentry psID="16" percentarea=" 
<urbandet rks="10.0000"> 


EQ" 


</vnotchweir> 
</urbandet> 
</psentry> 
// Unconnected Impervious land 
<psentry psID="18" percentarea=" 25.0" 
<imperv sdet="0.0328" isto="0.0984"></imperv> 
</psentry> 
// Directly connected Impervious land 
<psentry psID="19" percentarea=" 27.0" 


</psentry> 
// Pervious land 








<vnotchweir wlen="0.71" angle="20.0" top="6.42" apx=" 


runoff="homecell"> 


5.69"> 


runoff="ps-17"> 


runoff="ps-16"> 
<imperv sdet="0.0328" isto="0.1312" dirconn="1"></imperv> 





























</HPM> 





<psentry psID="17" percentarea=" 10.0" runoff="ps-16" wsupply="hub"> 
<afsirs coupled="no"> 
<afcrop label="TURF,LNDSCP." id="16" 31="1-1" Jjn="12-31" depthl=" 6" 
depth2="24"> 
<kctbl> 
0.40 0.40 0.40 0.90 0.99 0.99 
0.99 0.99 0.99 0.90 0.50 0.40 
</kctbl> 
<awdtbl> 
0.50 0.50 0.50 0.50 0.50 0.50 
0.50 0.50 0.50 0.50 0.50 0.50 
</awdtbl> 
</afcrop> 
<afirr label="SPRINKLER, LARGE GUNS " wtd="2.5"> 
<irrmeth id ="6" eff="0.85" arzi="0.9" exir="0.8"></irrmeth> 
<irrmgmt label = "DROUGHT" trigcode="1 value=0.10"></irrmgmt> 
</afirr> 
<afsoil label=" dirt" depth="80" minwc="0.09" maxwc="0.15" cond="1"> 
</afsoil> 
</afsirs> 
</psentry> 
</hub> 
</entry 
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The Afsirs model requires parameters to describe the crop, soil, irrigation system and irri- 
gation management plan (Table 5.18). An example of the XML that implements <afsirs> 
HPMs is presented in Table 5.19 and Table 5.20. 


Table 5.18:Elements and attributes used for the <afsirs> HPM. 









































<Element> Definition Dimen- | Variable Suggested Default Example 
or Attribute sions type range 
<afsirs> Designates the <afsirs> type HPM 
label Description of HPM NA String Any String unspecified | Eric’s Farm 
coupled Is water table coupled with | NA String Yes or No no Yes 
water table in mesh cell(Yes) 
of does afsirs maintain sepa- 
rate soil water accounting 
<afcrop> Designates attributes for the <afcrop> subelement 
label Description of crop NA String Any String unspecified | Strawberries 
id crop id NA Integer (1-16, perennial | Req. 23 
crops, 17-44 
annual crops) 
jl Crop season start date NA string 1-1 to 12-31 Req. 10-1 
(month- 
date) 
jn Crop season end date NA string 1-1 to 12-31 Req. 2-15 
(month- 
date) 
depth1 Irrigated soil depth | L Real 0.0 - 48.0 Req. 6.0 
(in)(perennial crops) 
Early season irrigated soil | L Real 0.0 - 48.0 Req. 12.0 
depth (in) (annual crops) 
depth2 Root depth (in) (perennial | L Real 0.0 - 48.0 Req. 9.0 
crops) 
Late season irrigated soil | L Real 0.0 - 48.0 Req. 27.0 
depth (in) (annual crops) 
Skenbii Table of 12 monthly crop ET | NA Real 0.0-1.0 No default | 0.90 0.90 0.90 0.90 
coefficients (perennial crops) 0.99 0.99 0.99 0.99 
0.99 0.90 0.90 0.90 


























Table 5.18 continued on next page 
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<Element> Definition Dimen- | Variable Suggested Default Example 

or Attribute sions type range 
or 
Table of 6 values: Peak crop | NA Real 0.0-1.0 No default 1.05 0.75 0.22 0.30 
ET, crop ET coefficient at 0.30 0.18 
harvest, and fraction of grow- 
ing season in each of four crop 
growth stages (annual crops) - 
Total of 12 values 

<awdtbl> Table of 12 monthly values | L Real 0.0-1.0 No default | 0.67 0.67 0.33 0.33 
for allowable soil water deple- 0.33 0.33 0.67 0.67 
tion before irrigation (peren- 0.67 0.67 0.67 0.67 
nial crops) oo 
or 
Table of 4 values of allowable | L Real 0.0-1.0 No default | 0.40 0.40 0.40 0.65 
soil water depletion by crop 
growth stage (annual crops) 

<afirr> Designates the <afirr> type subelement 

label Description of irrigation | NA String Any String No default | Sprinkler, Large 
method Guns 

wtd Managed water table depth L Real 0.0-5.0 Req. 2.5 

<irrmeth> Designates the <irrmeth> type subelement 

label Description of the irrigation | NA String Any string No default | Drip Irr 
method 

id Number for irrigation method | NA Integer See AFSIRS docu- | Req. 6 
type mentation 

eff Irrigation application effi- | NA Real 0.0-1.0 Req. 0.7 
ciency 

arzi Fraction of area of parcel irri- | NA Real 0.0-1.0 Req. 0.9 
gated 

exir Fraction of crop water use ex- | NA Real 0.0-1.0 Req. 0.95 
tracted from irrigated soil 

drinc Flood storage depth for rice | L Real 0.0-60.0 0.0 3.0 





(in) 


























Table 5.18 continued on next page 
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<Element> Definition Dimen- | Variable Suggested Default Example 
or Attribute sions type range 
crown Citrus bed height (in) L Real 0.0-36.0 0.0 1.5 
<irrmgmt> Designates the <irrmgmt> type subelement 
label Irrigation management sce- | NA String Drought or Nor- | No default | Normal 
nario mal 
trigcode Designates irrigation trigger NA Integer 0 - optimum irri- | Req. 
gation 
1 - fixed irrigation 
rate (in/day) 
2 - irrigate at fixed 
soil water deficit 
value Fixed irrigation rate (in/day) | LT! Real 0.0-2.0 0.0 0.2 
or fraction of ASW at which 
irrigation is applied 
<afsoil> Designates the <afsoil> type subelement 
label Soil type description NA String Any soil Descrip- | No default | Myakka fine sand 
tion 
depth Thickness of soil (in) L Real 0.0-200.0 Req. 80.0 
minwc minimum soil water holding | L Real 0.0-0.5 Req. 0.09 
capacity (in) 
maxwc maximum soil water holding | L Real > minwe — 0.8 Req. 0.15 
capacity (in) 
cond condition code for selecting | NA Integer 1 — average Req. 
available soil water capacity 
2 — minwc 1 














3 — maxwc 














NA = Not Applicable; Req. = Required. 
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5.4.2.2 Drainage Collector Ditch HPM <pumpedditch> 


The pumped ditch HPM simulates canal storage that is controlled by a pump. The canal 
storage can be a series of collector ditches or a detention storage area internal to a farm or 
a canal in a water control district/drainage district. The prototype is a large citrus grove 
or vegetable farm where runoff from the field flows to a large collector ditch system. The 
elements and attributes used in the <pumpedditch> HPM are provided in Table 5.21. 
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Table 5.19: Example XML for an <afsirs> HPM. 





<pseudocell> 
<indexed file="lu.index"> 
// perennial crop - irrigated pasture 


<entry id="211" label="Improved pasture"> 
<afsirs coupled="yes"> 
<afcrop label="TURF,LNDSCP." id="16" j1="1-— 1" Jjn="12-31" depthl=" 6" depth2="24"> 
<kctbl> 

0.90. 0290 O.80 G.90 0.99: 0,99 
0.99 0.99 0.99 0290 0.90 0.90 

</kctbl> 

<awdtbl> 
0.50 0.50 0.50 0.50 0.50 0.50 
0.50 0.50 0.50 0550 0.50 01:50 


</awdtb1> 
</afcrop> 
<afirr label="SPRINKLER, LARGE GUNS " wtd="2.5"> 
<irrmeth id ="6" eff="0.70" arzi="1.00" exir="1.00"> </irrmeth> 
<irrmgmt label = "NORMAL" trigcode="1" value="0.10"> </irrmgmt> 
</afirr> 
<afsoil label="ave dirt" depth="80" minwc="0.09" maxwc="0.15" cond="1"> </afsoil> 
</afsirs> 
</entry> 
// Citrus - crown flood 
<entry id="2211" label="citrus - crown flood"> 
<afsirs> 
<afcrop label="citrus" id="4" j1="01-01" jn="12-31" depth1l="30" depth2="60"> 
<ketbl> 
0.90 0,90. .0.90, 0.90 0.95 1.00 
1.00 1.00 1.00 1.00 1.00 1.00 
</kctbl> 
<awdtbl> 
0567 05.67 0'533- 0.5.33" .0.:33:-0..33 
0.67 0.67 0.67 0.67 0.67 0.67 
</awdtb1l> 
</afcrop> 


<afirr label="CROWN FLOOD" wtd="2.5"> 
<irrmeth id="8" eff="0.5" arzi="1.0" exir="0.7" crown="1.5"></irrmeth> 
<irrmgmt trigcode="0"></irrmgmt> 
</afirr> 
<afsoil label="0.8 SOILS" depth="96" minwc=".07" maxwc=".07" cond="1"> </afsoil> 
</afsirs> 
</entry> 
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// annual crop - tomato 
<entry id="2561" label="fall tomato - micro irrigation"> 
<afsirs> 
<afcrop label="tomato" id="60" j1="09-01" jn="12-31" depth1="9" depth2="12"> 
<ketbl> 
105 0497S 0.22 0.30 0220 0.18 
</kctbl> 
<awdtbl> 
0.40 0.40 0.40 0.65 
</awdtb1> 
</afcrop> 
<afirr label="MICRO, SPRAY" wtd="3.0"> 
<irrmeth id="3" eff="0.8" arzi="0.4" exir="0.4"></irrmeth> 
<irrmgmt trigcode="0"></irrmgmt> 
</afirr> 
<afsoil label="0.8 SOILS" depth="96" minwc=".07" maxwc=".07" cond="1"> </afsoil> 
</afsirs> 
</entry> 
// Rice - seepage irrigation 
<entry id="9" label="rice - seepage irrigation"> 
<afsirs> 
<afcrop label="rice" id="49" j1="01-01" jn="04-30" depth1i="12" depth2="18"> 
<ketbl> 
by 20 1.05 0.25) 0.25 -0.25 0.25 
</kctbl> 
<awdtbl> 
0.00 0.00 0.00 0.00 
</awdtb1> 
</afcrop> 
<afirr label="SEEPAGE IRRIGATION" wtd="0.5"> 
<irrmeth id="9" eff="0.5" arzi="1.0" exir="1.0" drinc="1.0"></irrmeth> 
<irrmgmt trigcode="0"></irrmgmt> 
</afirr> 
<afsoil label="0.8 SOILS" depth="96" minwc=".20" maxwce=".50" cond="1"> </afsoil> 
</afsirs> 
</entry> 
</indexed> 
</HPM> 








Table 5.21: Elements and attributes and typical values used for the <pumpedditch> HPM as a component of a <hub>. 






































<Element> or | Definition Dimensions | Variable Suggested Default | Example 
Attribute type range 
<psentry> Designates the indexed <psentry> environment 
psID HPM ID NA Integer | 100000-200000 -1 134768 
wsupply Source of the water supply for | NA String ”homecell” ”wb- | homecell | well-342 
the entry nnn” ”well-nnn” 
where nnn is a 
water body or 
well ID 
percentarea Percent area of farm occupied | NA Real 0.0-15.0 100 8.5 
by collector ditches (%) 
runoff destination of runoff NA String Homecell or hub | homecell | Homecell 
<pumpedditch>| Designates the <pumpedditch> type HPM 
rks Seepage Coefficient (1/day) NA Real 0.001 — 0.1 Req. 0.025 
psize Maximum Pump discharge | LT~! Real 1.0 — 6.0 Req. 3.5 
rate (in/d) 
ptrig Depth above the land surface | L Real <0 Req. -1.0 
at which the pump is turned 
on (m) 


























NA = Not Applicable; Req. = Required. 
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Table 5.22: Example xml for <pumpedditch> HPM. 





<pseudocell> 
<indexed> 


<entry id="1"> 
<hub runoff="homecell" wsupply="homecell" sewer="homecell"> 





<psentry psID="2" percentarea="10" runoff="hub"> 
<pumpedditch rks="0.001" psize="0.5" ptrig="-2.0"></pumpedditch> 
</psentry> 





</hub> 
</entry> 
</indexed> 
</HPM> 











A simple example of the pumped-ditch HPM is presented in Table 5.22 and another in 
Benchmark 57. 


Although developed for large farms and groves, the pumped ditch can be used for golf 
courses, urban developments and internal canals of drainage districts where the discharge is 
controlled by a pump. 


5.4.2.3 Agricultural Impoundment HPM <agimp> 


The agricultural impoundment HPM was created to simulate the impoundments required 
by the Surface Water Regulation permitting process developed by SFWMD. All agricultural 
operations constructed since the mid-1980s have been required to construct an impound- 
ment to capture runoff such that post-development runoff does not exceed pre-development 
runoff. The Environmental Resource Permit Information Manual, Volume IV (SFWMD, 
2000) provides the design specifications for agricultural impoundments. The design specifi- 
cations provide criteria for the impoundment size and discharge structure (weir and bleeder) 
characteristics. The AgImp HPM uses input parameters to compute the size of the impound- 
ment and the design of the outlet structure, and then uses the resulting structure design to 
compute discharge from the impoundment as a function of stage. 












































Table 5.23: Elements, attributes and typical values used for the <AgImp> HPM as a component of a <hub>. 
<Element> or | Definition Dimensions | Variable Suggested Default | Example 
Attribute type range 
<psentry> Designates the indexed <psent ry>environment 
psID HPM ID NA Integer | 100000- -1 157843 

200000 
percentarea Percent area of parcel in im- | NA Real 5.0-25.0 100 8.5 
poundment(%) 
runoff destination of runoff NA String Homecell or | homecell | hub 
hub 
<agimp> Designates the <agimp> HPM 
rks Seepage coefficient (1/d) NA Real 0.001-0.1 Req. 0.03 
height Wetseason water table eleva- | L Real 0.0-45.0 Req. 23.6 
tion (ft -NVGD) 
rd root depth(bottom of storage) | L Real 0.0-5.0 Req 2.6 
<stdtriorif> | Creates the environment for the input of discharge parameters 
r25y3d Rainfall depth for 25-year, 3- | L Real 3.0 - 8.0 Req. 5.2 
day return period storm (ft) 
allow Allowable basin discharge | L?T7! Real 5.0 - 70.0 Req. 35.0 
(cfs) 
s Abstraction in the NRCS |L Real 0.7 - 1.0 Req. 0.85 
runoff method (ft) 


























NA = Not Applicable; Req. = Required. 
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Table 5.24: Typical example xml for an <agimp> HPM within a hub. 





<pseudocell> 
<indexed> 


<entry id="12" label="citrus with agimp" mode="one2many"> 
<hub wsupply="wb-21" runoff="wb-21"> 
<psentry psID="1" percentarea="90" 
runoff="ps-2" wsupply="hub"> 
é&écitrus_drip; 
</psentry> 
<psentry psID="2" percentarea="10" runoff="hub"> 
<agimp rks="0.0005" height="6.0" rd="4.0"> 
<stdtriorif r25y3d="0.792" allow="0.0625" s="0.85"> 
</stdtriorif> 
</agimp> 
</psentry> 











</hub> 
</entry> 
</indexed> 
</HPM> 











The elements and attributes used in the definition of an <agimp> HPM are listed in 
Table 5.23. A simple example of the <agimp> HPM is in Table 5.24. 


5.4.3 Urban Hubs <hub> 


Urban hubs include directly connected impervious areas (DCIA) such as parking lots, roads 
and storm sewers, unconnected impervious areas (UCIA) such as roofs and sidewalks, per- 
vious areas (PA) such as lawns and landscaped areas, a detention pond (Det) and a canal. 
The UCIA and DCIA areas could be modeled with the <imperv> HPM, the PA area by 
<afsirs> and the detention area by <urbandet>. The urban developments receive water 
from offsite public water supply wells (PWS), are self-served or have both where landscape 
irrigation comes from a local source. This is modeled as consumptive use, <cu>. Return 
flow to septic drain fields and sewer systems is also modeled. 
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5.4.3.1 Consumptive Use <cu> 


The distinction between consumptive (CU) and non-consumptive use of water is a critical 
aspect of effective water management. Consumptive use of water means that water is not 
directly returned to the water source from which it was withdrawn. Non-consumptive water 
use means that, after use, the water is directly returned to the source for use by others. 


The volume of CU for each parcel is determined by the land use type. A lookup table 
provides the volume of water used by each of the primary Florida Land Unified Classification 
System (FLUCS level II) urban classes. This information is based on data obtained from the 
USACOE to determine overall urban water use. The volume of CU in a hub is determined 
by the sum of the CU of each of the urban land uses. 


Consumptive use is simulated by the <cu> object that is defined within the <hub> 
environment. The elements and attributes used to specify consumptive use are detailed in 
Table 5.25. A simple example of the consumptive use HPM is presented in Table 5.26. 


Table 5.25: Elements and attributes for the <cu> object. 

















<Element> Definition Dimensions| Variable Suggested | Default | Example 
or Attribute type range 
<eu> Designates the <cu> environment 
label High density or low low urban | NA String HI or LI undefined | HI 

land use 
percentarea Percent area of the hub with | NA Real 0-100 Req. 50.0 

the specified consumptive use 

(%) 
wsupply Water supply source NA String ”homecell” homecell | hub 

or ” hub” 























Sub-elements available for flow for <wsupply> are <const>, <dss>, <asciiform>, <csv>, and <rc>. 
These are described in detail in section 6.1 





























<sewer> Indicates sewer environment 

fracloss Fraction of water lost from | NA Real 0.0-1.0 0.0 0.1 
sewer system to groundwater 

<septic> Specifies that the consumptive use goes to recharge, otherwise it goes to sewer flow 
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Table 5.26: Example «ml for consumptive use in HPM. 





<pseudocell> 
<indexed> 


<entry id="1"> 
<hub runoff="homecell" wsupply="homecell" sewer="homecell"> 





<cu label="HI" percentarea=" 50.00" wsupply="hub"> 
<const value=" 0.00361"></const> 
<sewer fracloss="0.1"></sewer> 

</cu> 

<cu label="LI" percentarea=" 50.00" wsupply="hub"> 
<const value=" 0.00361"></const> 
<sewer fracloss="0.1"></sewer> 

<septic></septic> 

</cu> 


</hub> 
</entry> 


</indexed> 
</HPM> 











5.4.3.2 Urban Stormwater Retention/Detention HPM <urbandet> 


Urban stormwater runoff may be collected and routed through a stormwater detention facil- 
ity. This facility may include detention for water quality treatment, a retention pond or a 
stormwater detention pond. The discharge structure is shown in Figure 5.5. The detention 
pond is simulated by the HPM <urbandet> in a hub. The elements and attributes used to 
specify an <urbandet> HPM in a hub are presented in Table 5.27 and in Benchmark 52. 


CHAPTER 5. HYDROLOGIC PROCESS MODULE APPROACH AND MODELS 227 





Figure 5.5: Structure dimensions of the <urbandet> HPM discharge weir and bleeder. 


Table 5.27: Elements and attributes for the <urbandet> HPM as a component of a <hub>. 









































<Element> or | Definition Dimen- Variable Suggested Default | Example 
Attribute sions | type range 
<psentry> Designates the indexed <psent ry>environment 
psID HPM ID NA Integer | 100000-200000 | -1 157843 
wsupply Source of the water supply for the en- | NA String ”*homecell” homecell | well-342 
try ” wh-nnn” 
” well-nnn” 
where nnn is a 
water body or 
well ID 
percentarea Percent area of parcel in impound- | NA Real 5.0-25.0 100 8.5 
ment(%) 
runoff Destination of runoff NA String Homecell or | homecell | homecell 
hub 
<urbandet> Designates the <urbandet> environment 
rks Seepage coefficient for flow between | NA Real 0.001-0.1 Req. 0.007 
the detention basin and the aquifer 
<vnotchweir>| Designates the <vnotch weir> outlet structure 
wlen Length of rectangular weir (m) L Real 0.0 - 10.0 Req. 7.5 
angle Angle of V-notch weir (degrees) NA Real 0 - 120 Req. 75.0 
top Elevation of top of v-notch bleeder | L Real 0 - 20 Req 13.6 
and invert of the rectangular weir (m, 
NGVD) 
apx Elevation of invert of v-notch bleeder | L Real 0 - 20 Req 11.4 





(m, NGVD) 























NA = Not Applicable; Req. = Required. 
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Table 5.28: Example xml for <urbandet> HPM in a hub. 








<pseudocell> 
<indexed file="lu.index"> 


<entry id="1"> 
<hub runoff="homecell" wsupply="homecell" sewer="homecell"> 














<psentry psID="23" percentarea="10.0" runoff="homecell"> 
<urbandet rks="0.001"> 
<vnotchweir wlen="10.0" angle="21.0" top="10.58" apx="9.75" /> 
</urbandet> 
</psentry> 





</hub> 
</entry> 
</indexed> 
</HPM> 





A simple example of the urbandet HPM is presented in Table 5.28. 
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Table 5.29: Example index file for assigning HPMs to mesh cells. 





DATASET 

OBJTYPE "mesh2d" 
BEGSCL 
ND 18 
NAME "landuse type" 
TS 0 0.0 

















WWNN NEFF EF 











5.4.4 Assignment Of HPMs To Various Land Use Types <indexed> 


Each cell in the model is assigned a particular type of HPM depending on the land use type. 
Cell ID’s are used to assign cells or fractions of cells to the HPMs as needed. An index is 
assigned for each HPM type, and an index file is used to associate the cell ID’s with the HPM 
types. An indexed entry element <indexed> can be used where multiple HPMs must be 
defined. To assign various HPM types to various cells, areal index maps are used. In using 
this method, a GMS type data file is used to assign various cell ID’s to HPM type indices. 
The example in Table 5.29 below shows one of these index files used in Benchmark 14. 
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Table 5.30: Example XML for implementation of kveg parameter modification. 





<pseudocell> 
<indexed file="lu.index"> 


<entry id="3"> 
<layerinsm kw="1.0" rd="0.5" xd="2.0" pd="3.0" kveg="0.00"> 
<ampmod para="kveg"> 


1 0.75 

15 0.75 

16 1.0 

365 1.0 
</ampmod> 
</layerinsm> 

</entry> 
</indexed> 


</HPM> 











5.4.5 Time Variation of HPM Parameters <ampmod> 


Particularly for agricultural HPMs it is appropriate to vary parameters with the season of 
the year. As an example, the <afsirs> HPM internally computes irrigation requirements 
as a function of the phase of the growing season. A parameter that might reasonably be 
varied seasonally is potential evapotranspiration. There is a mechanism available to allow 
for modifying selected parameters to take this effect into consideration. This option is cur- 
rently implemented in the <layerlnsm>, <layer5>, and <unsat> HPMs. The most 
commonly used parameter with seasonal variability is the vegetation crop ET coefficient, 
kveg. The seasonal variability is implemented using a keyword <ampmod> meaning ” am- 
plitude modulation”. This allows the use of a 1-D lookup table to describe the variation of 
the parameter during the year, kveg as an example. In the following example in Table 5.30, 
kveg is 0.75 for the first 15 days of the year, and 1.0 for the rest of the year. The XML 
element is <ampmod> and the only attribute is ”para” that can be any parameter in the 
HPM. Following the ” para” attribute designation RSM will read a 1-D lookup table entered 
as text as in the example below. The text consists of pairs of numbers specifying ” serial day 
of the year” and ” multiplier for attribute”. The user must determine which parameters are 
appropriate candidates for annual variation. 


Chapter 6 


Input and Output File Specifications 


Model input and output data can be in several formats. In this chapter the methods for 
specifying input data at a single location are described. Constant, repeating, and time series 
data are included. 
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6.1 Time Series and Other Data Formats Used For Single Location 
Model Input 


Data at a single location in the model which is required for a boundary condition, rainfall, or 
evapotranspiration, may be input as a constant, a rating curve or as a time series. Examples 
where each of these could be appropriate include a constant water level in a water body 
where the level is maintained by pumping into or out of the water body, a rating curve that 
describes evapotranspiration that varies with the season but remains unchanged from year 
to year, and time series of daily rainfall for the duration of a multi-year model run. Constant 
data are input in the <const> environment, repeating time dependent input as a rule curve 
under <rc>, and time series data in the <dss> format. 


6.1.1 Constant Value 


A constant value can be specified with a very simple XML construction. The elements and 
attributes available are shown in Table 6.1 


Table 6.1: Elements and attributes used to define a <const> input value. 





























<Element> | Definition Dimensions Variable| Suggested Default | Example 
or Attribute type range 
<const> Designates a <const> input. 
dbintl The time interval of the sim- | T Real 60-2880 1440 1440 
ulation in minutes. 
value Value of the input variable. NA Real Any real Req. 1.34 
mult Multiplier for the value. May | NA Real Any real 1.0 0.3048 
be used to change units. 
units Units of the input. NA String Any string No 
default 
type Valid DSS data type. NA String Valid DSS data | No 
type default 


























NA = Not Applicable; Req. = Required. 
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Table 6.2: Sample XML for specifying a constant <refet>. 





<refet> 
<const dbintl="1440" value="0.14" mult="0.3048" </const> 
</refet> 











An example of XML input that specifies a constant <refet> of 0.14 with a multiplier 
of 0.3048 to convert from feet to meters is shown in Table 6.2 


6.1.2 Rule Curve 


A rule curve describes a variable that varies during a year and then repeats that behavior 
during each succeeding year. Common examples are reservoir operations for which there is a 
target headwater elevation for each season. For most large reservoirs in temperate climates, 
for example, the water is maintained at a high level during the late spring and summer, and 
then lowered in the fall to furnish flood storage volume for the winter months when more 
runoff is expected. In SFRSM, rule curves may be used for seasonal evapotranspiration, 
irrigation requirements, and other variables. When used to input a variable, a rule curve is 
referenced by number. Rule curves are created in the <rulecurves> environment. The 
elements and attributes for defining and using a rule curve are explained in Table 6.3. An 
example showing the creation and use of a rule curve shown in Table 6.4 is used in Benchmark 
52. 


Table 6.3: Elements and attributes used to define a rule curve and to use it. 
























































<Element> or | Definition Dimen- Variable} Suggested Default | Example 
Attribute sions | type range 
Element and attribute for defining rule curves. 
<rulecurves> | Designates rule curves will be defined. 
<reent ry Designates that a particular rule curve will be specified. 
id The ID number of the rule | NA Integer | any integer Req. 3 
curve 
label A label to describe the rule | NA String Any string Uns. seasonal 
curve. water 
level 
xunits Units for the first column | NA String A valid DSS | Req. 1DAY 
(time) in a 1D lookup table. time interval 
cycle The time length of the rule | NA String A valid DSS | Req. 1YEAR 
curve. time interval 
yunits Units of the variable. NA String Any string Req. 1YEAR 
type The type of data. NA String INST-VAL Req. INST- 
PER-AVER VAL 
PER-CUM 























A table of x and y values in two columns to define the rule curve. See the example in Table 6.4 





Element and attribute for applying a rule curve. 





<ice> 


Designates the data specified by a rule curve. 





id 


The id number of the rule 
curve. 





NA Integer 








Any rule curve 


id 





Req. 











NA = Not Applicable; Req. = Required; Uns. = Unspecified. 
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6.1.3 DSS Time Series 


The most common time series format for single station data input has been the US Army 
Corps of Engineers (USACE) Hydrologic Engineering Center (HEC) DSS format. DSS stands 
for Data Storage System adopted by HEC. A file may contain many sets of time series data 
with each time series referenced by a path names. Each path name has six parts; A, B, 
C, D, E and F as described in Table 6.6. DSS files are described in detail in (Hydrologic 
Engineering Center, 1994). The elements and attributes used for specifying the data in a 
DSS file are explained in Table 6.5. An example of a DSS path name is shown below. 


A B ie D E FEF 
/RED RIVER/BEND MARINA/FLOW/01JAN1975/1DAY/OBS/ 




















The same path name with the optional parts omitted still requires the slashes (/) to be 
a valid path name. 


B C E 
//BEND MARINA/FLOW//1DAY// 
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Table 6.4: Sample XML for specifying a rule curve <rc> and using it in the specification of mesh 
boundary conditions.. 





<rulecurves> 
<rcentry id="1" label="seasonal water level" xunits="lday" 
yunits="m" type="INST-VAL" cycle="1YEAR"> 








1 498 

90 498 

120 500 

300 500 

330 498 

366 498 
</rcentry> 
</rulecurves> 


<mesh> 
<geometry file="mesh3x3.2dm"> </geometry> 
<mesh_bc> 
<wallhead section="gw"> 
<nodelist> 1 2 3 4 </nodelist> 
<uniform> <rc id="1"></rce> </uniform> 
</wallhead> 
<wallhead section="gw"> 
<nodelist> 13 14 15 16 </nodelist> 
<uniform><re id="1"></re></uniform> 
</wallhead> 
</mesh_bec> 














Table 6.5: Elements and attributes used for specifying time series data in a <dss> file. 












































<Element> | Definition Dimen- Variable} Suggested Default | Example 
or Attribute sions | type range 
<dss> Designates a <dss> file. 
file The name of the DSS file | NA String Any valid DSS | Req. RRFlow.dss 
file name 
pn The DSS path name of the | NA String A valid DSS | Req. /REDRIVER/BEND 
times series in the DSS file path name e AB OES / 
mult A multiplier for the data NA Real Any Real 1.0 0.02831685 
units Units of the variable NA string Any string Imp. cfs 
type Type of data NA String See Table 6.7 Imp. PER-CUM 








NA = Not Applicable; Req. = Required; Imp. = Implied 








SNOLLVOIAIOddS ATA LAdLNO ANV LNdNI 9 YALdVHO 


6€% 


CHAPTER 6. INPUT AND OUTPUT FILE SPECIFICATIONS 240 


In SFRSM a number of variable types are assigned default units. If other units are 
to be used, the ”multiplier” option needs to be used to convert the units as appropriate. 
Head measurements for example use METERS as the default unit with type INST-VAL. 
The remaining unit sets are shown in Table 6.7. 
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Table 6.6: Path name definition for time series data in DSS format. 






































Part Description Format Acceptable values 

A Basin or project name. (op- | String Any string 

tional) 

B Location or gage identifier | String Any String 

(required). 

C Data variable or parameter. | String FLOW, STG, 
FLOW-CUM, 
ELEV, STAGE, 
PH, PRECIP, etc 
(required). 

D Starting date for block data | ddmmmyyyy | 01JAN1981 (op- 
tional) 

E Time interval. String IMIN, 2MIN, 3MIN, 
4MIN, 5MIN, 
10MIN, 15MIN, 
20MIN, 30MIN, 
1HOUR, 2HOUR, 
3HOUR, 4HOUR, 
6HOUR, 8HOUR, 
12HOUR, 1DAY, 
1WEEK, 1MON, 
1YEAR (required) 

F Additional user-defined data | String Any String  (op- 
tional) 
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Table 6.7: Default units used by the RSM model. 























Quantity Unit Type 

Head METERS INST-VAL 
Flow CU_METER/SEC INST-VAL 
Rain METERS PER-CUM 
ET METERS /time step PER-CUM 
Depth METERS INST-VAL 
Water level METER INST-VAL 








Transmissivity | METER?/SECOND PER-AVER 
Definition of Unit Types 

















Type Definition Example 

PER-AVER Period Average Daily flow 

PER-CUM Period Cumulative Monthly flow (volume) 
INST-VAL Instantaneous Breakpoint Stage 

















INST-CUM Instantaneous Cumulative | Rain mass curve 





Chapter 7 


RSM Post-Processing 


This chapter contains four topics related to post-processing RSM, including: 


1. A review of RSM water budgets for water bodies and water movers (section 7.1). A 
local and global water balance discussion is also provided in this chapter. 

2. RSM output options (section 7.2) specified in the XML input files 

3. RSM uncertainty analysis (section 7.3) 


4. RSM graphical user interface (section 7.4 currently under development) 
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7.1 Water Balance And Budgets 


Keeping track of water is a basic responsibility of the water bodies and the water movers, 
which are the basic building blocks of the HSE. Water bodies, regardless of their sizes or 
shapes, track how much water is contained in them at the end of every time step. Similarly, 
water movers regardless of their size or shape should know the volume of water that pass 
through them. All the water budgets are tied to the governing equations and the finite 


volume method. aq 
where Q(H) = flows into the water bodies in vector form; S = water entering water bodies 
through recharge. Recharge occurs after ET, rain, unsaturated flow storage, etc. and all are 


taken into account. 


Water in a water body can be stored in a saturated compartment and in a HPM com- 
partment. The saturated water is used with the stage-volume (SV) relationship to compute 
the water level. Saturated ground water, canal water, lake water and overland flow water 
all fall into this category. HPMs represent the local hydrology which may account for water 
above the water table. Water in the HPM takes into account the unsaturated water, urban 
detention, agricultural residue, etc. This water does not relate to the water level in the 
regional system. 


Within a time step in the computations, the following water balance equation can be 
written for the total water content. 


yinty) + vit) _ ve") = y™ =Q. +Qa+Q:+Qi +Q (7.2) 


The components are defined in Table 7.1 and Table 7.2. 


7.1.1 Water Budgets Of Water Bodies 


Water bodies have heads H associated with them, which drive the water movers. The 
volume of water in a cell has two water budget components due to their contribution from 
the saturated cell and the HPM. Only the saturated water is related to the head in the water 
body. The reported components of water are listed in Table 7.1. 


7.1.2 Water Budgets Of Water Movers 


Water movers provide the only way to move water in and out of a water body. Any water 
moving through a water mover is accounted for. The reporting categories of moving water 
are divided into the following categories. 
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Table 7.1: Reported water budget components of a water body. 





Component 


Variable 


Definition 





<saturated> 


Vs 


This is the total volume of water in the water body below 
the free surface. This water includes saturated ground 
water and overland flow water. The SV converter can 
be used to compute the relationship between this volume 
and the head. 





<pseudo> 








This is the volume of water in the water body that is not 
in the saturated head dependent water body. This vol- 
ume is made up of unsaturated water, detention ponds, 





and water in the process of being routed in urban cells. 








Table 7.2: Reported water budget components of a water mover. 





Component 


Variable 


Definition 





<recharge> 


Qr 


Volume of water entering the saturated compartment of 
the water body from the HPM compartment as a re- 
sult of the internal processes of the HPM. Rainfall, ET, 
and unsaturated flow storage and other local hydrological 
functions enter into the computation. 





<drainage> 


Qa 


Volume entering the saturated compartment of the water 
body as a result of non-recharge type or planned releases 
from its own or other HPMs. Such releases take place 
in urban and agricultural areas. This water adds to the 
source term in the computations. 





<srcbnd> 


Qs 


Volume of water entering into the saturated water body 
as a result of pumping, and similar source types that are 
entered as source/sink boundary conditions. 





<inflow> 


Qi 


Volume of water that enters the saturated part of the 
water body through the water movers. This is known at 
the end of the time step. 





<borrow> 











Volume of water entering into the saturated water body 
after the entire horizontal flow computations are com- 
plete, when the water left in a water body is negative. 
This is common when the canals are dry and pumping 
continues. 
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7.1.3 Local and Global Mass Balance 


The governing equations solved by RSM are conservative and mass balance should be 
achieved both locally and globally in well-posed problems. However, the use of constant 
head boundary condition for a water body (cell, segment or a lake) can cause a mass imbal- 
ance in the model because it cause the entire row of the solution matrix to be replaced by 
a row of zeros and a diagonal term during the assignment of the boundary condition. The 
process of elimination of terms destroys the integrity of the water movers, which guarantee 
the mass balance of RSM. This affects the mass balance of surrounding cells, which rely on 
water movers for the flow information. This may, however, not affect the mass balance of 
far away cells. The replacements for head boundary conditions for cells or segments can be 
wall or node based, respectively. 
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7.2 RSM Output Options <output> 


A number of model output options are available for both state variables and parameters 
using the <output> option. These options can be classified into three categories. 


1. Under the first category of options, a comprehensive export of a selected set of variables 
is possible. This output is in GMS format and can be used for GMS or TECPLOT 
animations. This type of export will include all the cell, segment, or lake values at all 
times. 


2. Under the second category, a netCDF export is possible. This file can be post-processed 
using a budget package/budget tool. The budget tool gives a balance of budget com- 
ponents as well as other debugging capabilities indicating whether some of the model 
objects were ever created. 


3. Under the third category, it is possible to export various monitors for a selected set 
cells at a selected intervals. This option can be used to focus on small areas. 


The list of all available options under these three categories is shown in Table 7.3. The 
output file formats available under most of the output options is listed in Table 7.4. Details 
on some of the most important options are described below, with examples. 
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Table 7.3:Model output options available using <output>. 





Elements 


<globalmonitor> 





Description 


Used to dump all the values of a variable for the entire dura- 
tion of the model run. The list of attributes available under 
this option are in Table 7.5. The format used can be <gms> 
with filename file = "myfile.dat" or any other format 
in Table 7.4. 





<budget> 


Options available are as in  budget="Lm43" 
dbintl="10080". 





<budgetpackage> 


The entire water budget is dumped into a designated 
netCDF file for post processing. A program ”psbud” 
is used to for this purpose. The only options under 
<budgetpackage> are file name and data base interval as 
in budgetpackage="C4.nc" dbintl="1440" showing 
output data interval. 





<psbudgetpackage> 


The entire water budget is dumped into a designated netCDF 
file to be used later in post processing. A program ” ps- 
bud” is used to for this purpose. The options available under 
<budgetpackage> are as in budgetpackage="C4.nc" 
dbintl="1220". 





<cell 





report> 


The option available is file="mon.dat" 





<cel 








Imonitor> 





Useful in monitoring a large number of attributes. The op- 
tions available are cell ID <id> and <attr>. The list of 
attributes is shown in Table 7.6. 





<segmentmonitor> 


Useful in monitoring a large number of segment attributes. 
The options available are segment ID <id> and <attr>. 
The list of attributes is shown in Table 7.7. 





<junctionmonitor> 


Useful in monitoring flow in junctions. The available options 
are <id1l>, <id2> and <attr>. The list of attributes is 
shown in Table 7.8. 














<wmmonitor> Useful in monitoring water movers. The available options 
are <wmID> and <attr>. The list of attributes is shown in 
Table 7.9. 

<bcmonitor> Useful in monitoring boundary conditions. The available op- 





tions are <bcID> and <attr>. The list of attributes is 











shown in Table 7.10. 





Table 7.3 continued on next page 
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Elements 


<lakemonitor> 


Description 





Useful in monitoring lakes. The available options are <idD> 
and <attr>. The list of attributes is shown in Table 7.11. 





<assessormonitor> 


Used to monitor assessors. The attributes include <ormid>, 
<aid> and <attr>. The list of attributes is shown in Ta- 
ble 7.12. 





<ctrilmonitor> 








Used to monitor controllers. The attributes include <wmID> 
and <attr>. The options available under <attr> are de- 
scribed in Table 7.13. 





<flowgage> 


Useful in monitoring flow across flow lines. The available 
options are <section> and <nodelist>. The list of 
<section> options included are shown in Table 7.14. The 
keyword <nodelist> is a list of nodes defining the flow line. 








<pseudomonitor> 





Useful in monitoring attributes within the HPMs. The avail- 
able options are <id> and <attr>. The list of attributes is 
shown in Table 7.15. 
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Table 7.4: Time series formats available within the output options in Table 7.3. 









































Element Description 

<gms> GMS format, to be used as in <gms file="c51.gms" /> 

<netcdf> | netCDF format, to be used as in <netcdf file="c5l1.nc" 
dbintl="18000" /> 

<dss> DSS format, to be used as in <dss file="c51.dss" 
dbintl="18000" /> 

<csv> Comma separated ASCII format, as in <cvs file="c51.cv" 
dbintl="18000" label="My name" /> 

<ascii> | ASCII format, as in <asciiform file="c51.txt" 


format="%5d %5d %5d" />, which outputs the date (year 
month day) and the value in simple ASCII format. Any c-style formats 


are allowable, but floating point output formats are normally used 
such as (%lg %10.21f of). 














7.2.1 Saving Model Output <globalmonitor> 


The head, velocity and a number of other variables (Table 7.5) in the entire domain for the 
entire duration can be output into an ASCII file in GMS format using <globalmonitor> 
option. Table 7.3 shows the file formats available for saving the file. The output information 
can be used to create animations using GMS software or TECPLOT software after post 
processing using the hse2tec program. The following is an example of a data input included 
in the XML file to obtain both head and velocity data sets in GMS format. 





<output> 

<globalmonitor attr="totalvector"> 
<gms file="outvect.dat"> </gms> 

</globalmonitor> 
<globalmonitor attr="head"> 

<gms file="outheads.dat"> </gms> 
</globalmonitor> 

</output> 




















7.2.2 Water Budget Post-Processing 


Considering that a large number of variables are involved in water budget calculations, this 
task is often most suitable outside of the model as a post-processing exercise. The first step in 
budget post processing is to create a netCDF file from the model run. This is accomplished 
using <budget>, <budgetpackage> or psbudgetpackage> as shown in Table 7.3. 
These tags will create the netCDF files at the requested time interval in minutes specified 
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Table 7.5: 


Attributes available with <globalmonitor>. 


attr="attribute”> <filetype in Table 7.3 > < /globalmonitor> 


Global Monitor 


The usage is: 
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<globalmonitor 






























































Element Description 

ponding Ponding. 

wtdepth Ponding. 

head Water head in cells 
recharge Recharge into cells 
runoff Runoff from cells 
wsupply Water supply in cells 
rain Rain in cells 

refet Reference ET in cells 
rainvol Rainfall volume in cells 
rchgvol Recharge volume in cells 
watercontent Water content in cells 
wevol Water content in cells 
inflow Inflow into cells 
waterlevel Water level in cells 

sy Storage coefficient 
transmissivity | Transmissivity 
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Table 7.6: Variables that can be monitored using <cellmonitor>. The usage is: <cellmonitor 
id="cellid#” attr="attribute”> <filetype in Table 7.3 > < /cellmonitor> 


Cell Monitor 













































































Attribute Name Description Assessor 
ponding PondDepth depth of water above land sur- | Cell::Ponding() 
face 
wtdepth WTDepth depth to water table Cell::Wtdepth() 
head ComputedHead | elevation of water table Cell::Head() 
recharge Recharge volume of recharge received from | Cell::RechargeVolume() 
HPM 
runoff Runoff Volume volume of runoff received from | Cell::RunoffVolume() 
HPM 
wsupply Westinghouse volume of water supply with- | Cell::Westinghouse() 
drawals by HPM 
rain Rainfall depth of rainfall Cell::Rainfall() 
rainvol RainfallVolume | volume of rainfall Cell::Rainfall Volume() 
rchgvol RechargeVolume | volume of recharge received from | Cell::RechargeVolume() 
HPM 
watercontent| WaterContent depth of saturated water content | Cell::WaterContent() 
initvol Init Vol volume of initial water content Cell::Init Vol() 
wevol WCVolume volume of saturated water con- | Cell::SatVol() 
tent 
topo Topography land surface elevation Cell::LandSurface() 
inflow Inflow volume of inflow from adjacent | Cell::Delta() 
water bodies in previous time 
step 
waterlevel WaterLevel head - land surface Cell::WaterLevel() 
sy Specific Yield specific yield (depth fraction) Cell::Sy() 
transmissivitylransmissivity aquifer transmissivity Cell::TransValue() 
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Table 7.7: Variables that can be monitored using <segmentmonitor>. The usage 
is: <segmentmonitor id=”"segmentid#” attr="attribute”> <filetype in Table 7.8 > < 
/segmentmonitor> 
Segment Monitor 
Attribute Name Description Assessor 
head segmenthead elevation of water level Segment::Head() 
segmenthead segmenthead elevation of water level Segment::Head() 
depth segmentdepth depth of water Segment::Depth() 
segmentdepth | segmentdepth depth of water Segment::Depth() 
sbflow sbflow sum of all streambank flow in | Segment::SBFlow() 
segment 
seepageflow seepageflow streambank flow - aquifer | Segment::SeepageFlow() 
seepage 
overbankflow | overbankflow streambank flow — overbank | Segment::OverbankFlow() 
flow 
levl flow levl flow streambank flow — type 1 levee | Segment::Lev1Flow() 
seepage 
lev2flow lev2flow streambank flow — type 2 levee | Segment::Lev2Flow() 
seepage 
sbvolume sbvolume sum of all streambank flow | Segment::SBVolume() 
volumes 
seepagevolume | sbvolume streambank flow volume - | Segment::SeepageVolume() 
aquifer seepage 
overbankvolum¢ sbvolume streambank flow volume - | Segment::OverbankVolume() 
overbank flow 
levl volume sbvolume streambank flow volume - | Segment::Lev1Volume() 
type 1 levee seepage 
lev2volume sbvolume streambank flow volume - | Segment::Lev2Volume() 
type 2 levee seepage 
initsegsto InitSegSto initial volume of storage Segment::Init Vol() 
segsto SegmentStorage | volume of storage Segment::SatVol() 
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Table 7.8: Variables that can be monitored using <junctionmonitor>. The usage is: 
<junctionmonitor idl=”segment! id#” id2=”"seqgment2 id#” attr= “attribute”> <filetype in Ta- 
ble 7.38 > < /junctionmonitor> 


Network Junction Monitor 





Attribute Name Description Assessor 




















flow JunctionFlow volume of flow through junction | WaterMover::ReportFlow() 





Table 7.9: Variables that can be monitored using <wmmonitor>.The usage is: <wmmonitor 
id1="segment1 id#” attr= ”attribute”>< filetype in Table 7.8 > < /wmmonitor> 


Watermover Monitor 























Attribute Name Description Assessor 
flow WaterMoverFlow| volume of flow through water | WaterMover::ReportFlow() 
mover 





Table 7.10: Variables that can be monitored using <bcmonitor>. The usage is: <bemonitor 
bcID="bcid#” attr="attribute”> <filetype in Table 7.8 > < /bemonitor> 








Boundary Condition Monitor 


























Attribute Name Description Assessor 
flow BCVolume volume of flow through boundary | ExternalBC::ReportFlow() 
head BCHead head applied at boundary ExternalBC::Value() 





Table 7.11: Variables that can be monitored using <lakemonitor>. The usage is: <lakemonitor 
id="lakeid#-” attr="attribute”> <filetype in Table 7.38 > < /lakemonitor> 


Lake Monitor 














Attribute Name Description Assessor 
lakesto LakeStorage volume of lake storage Lake::Sat Vol() 
initlakesto InitLakeSto initial volume of storage Lake::Init Vol() 
head LakeHead elevation of water level Lake::Head() 
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Table 7.12: Variables that can be monitored using <assessormonitor>. The usage is: 
<assessormonitor ormid="ormid#” aid="aid# ”attr="attribute”> <filetype in Table 7.3 > < 
/assessormonitor> 








Assessor Monitor 


























Attribute Name Description Assessor 
depth Assessor Depth depth of water in waterbody Assessor::Depth() 
volume AssessorVolume | volume stored in waterbody Assessor:: Volume() 





Table 7.13: Variables that can be monitored using <ctrilmonitor>. The usage is: <ctrlmonitor 
wmID="wmid#” attr="attribute”> <filetype in Table 7.3 > < /ctrlmonitor> 


Control Monitor 
































Attribute Name Description Assessor 

error ControlError error Controller::ReportError() 
control ControlOutput | output Controller::ReportControlOut() 
state ControlState state variable Controller::ReportStateIn() 
maxflow ControlMaxFlow | flow Controller::Report MaxFlow() 








Table 7.14: Variables that can be monitored using <flowgage>. The usage is: <flowgage sec- 
tion= “attribute”> <filetype in Table 7.3 > < /flowgage> 


Flowline Monitor 











Attribute | Name Description Assessor 

ol OverlandFlow volume of overland flow across | FlowGage::OverLand() 
defined flowline 

gw GroundwaterFlow | volume of groundwater flow | FlowGage::GroundWater() 


across defined flowline 





ol_gw TotalFlow volume of total flow across de- | FlowGage::Total() 
fined flowline 
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Table 7.15: Variables that can be monitored using <psmonitor>. The usage is: <pseudomonitor 
id="HPM id#” attr= ’attribute”> <filetype in Table 7.3 > < /pseudomonitor> 


HPM Monitor 



















































































Attribute Name Description Assessor 
ps_celldeltavol | PS_CellDeltaVolume | volume of inflow HPM::CellDeltaVolume() 
ps_rechargevol | PS_RechargeVolume | volume of recharge to home- | HPM::RechargeVolume() 
cell 
ps_et PS_Et depth of evapotranspiration HPM::Et() 
ps_rain PS_Rain depth of rainfall HPM::Rain() 
ps_etvol PS_Et Volume volume of evapotranspiration | HPM::EtVol() 
ps_rainvol PS_RainVolume volume of rainfall HPM::RainVol() 
ps_watercontent PS_WaterContent depth of storage HPM::WaterContent() 
ps_wevol PS_WCVolume volume of storage HPM::WCVolume() 
ps_wsupply PS_WaterSupply depth of water imported for | HPM::WSupply() 
water supply 
ps_wslocal PS_WSLocal depth of water withdrawn | HPM::WSLocal() 
from homecell for water sup- 
ply 
ps_runoff PS_Runoff depth of runoff HPM::Runoff() 
ps_runoffvol PS_RunoffVolume volume of runoff HPM::RunoffVolume() 
ps_seepagevol | PS_SeepageVolume volume of seepage HPM::SeepageVolume() 
ps_wsupplyvol | PS_WSupplyVolume | volume of water imported for | HPM::Westinghouse() 
water supply 
ps_cuvol PS_CUVolume volume of import consump- | HPM::CUVolume() 
tive use 
ps_sewervol PS_SewerVolume volume of consumptive use | HPM::SewerVolume() 
return flow 
ps_septicvo PS_SepticVolume volume of consumptive use | HPM::SepticVolume() 
return flow — septic 
ps_wslocalvol | PS_WSLocalVolume | volume of water withdrawn | HPM::WSLocalVolume() 
from homecell for water sup- 
ply 
ps-initvol PS Init Vol initial volume of storage HPM::Init Vol() 
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using <dbintl1>. 


<output> 


<psbudgetpackage file="pseudo.nc" dbint1l="10080"></psbudgetpackage> 

<psbudgetpackage file="pseudo_yr.nc" dbintl="525600"></psbudgetpackage> 

<budgetpackage file="budget.nc" dbintl="10080"></budgetpackage> 
</output> 








where the file "budget .nc" is set to record time series data at 10080 minutes or 7 day 
intervals. 


Once the netCDF file is created, the water budget post-processor program ”psbud” is 
used to create a water budget for a cluster of cells listed in a ASCII file. When the command 
is used as shown below, it is assumed that there is access to the code in ”../../psbud/”. 


../../psbud/psbud -n pseudo.nc -s subset.unsat > unsat.out 


The file "subset .unsat" is simply an ASCII file with the required cells listed as shown 
below. 

1 

10 

32 

The following shows part of the output file "unsat.out" from the budget tool. In the 
file, the first three columns show the dates Jan 2, Jan 7, etc. indicating that the output is at 
the data base interval of 10800 min or 7 days as given in the <budgetpackage> example 
shown above. 


Rainfall Et CellDelta WSupply CU Sewer Septic Runoff Seepage Residual 

M^3 M*3 M*3 M*3 M*3 M*3 M*3 M*3 M*3 M*3 

1965 1 224 0 57150 74136 0 0 0 0 0 0 1341.8 32 
1965 1 9 24 0 O 1.4208e+05 0 0 0 0 0 0 19742 0 


The columns of the table show that various water budget components add to create a 
very small residual. The quantities shown are water budget volumes balanced during the 
time period. 


7.2.3 Monitoring Individual Points 


When individual objects of the model are to be monitored for state variables, a number of 
monitoring options are available through <cellmonitor>, <segmentmonitor>, etc. as 
described in Table 7.3. The attributes available for monitoring using these tags are described 
in the tables listed in Table 7.3. The following example shows a cell head monitor, lake head 
monitor, segment head monitor and watermover flow monitor: 


CHAPTER 7. RSM POST-PROCESSING 


<output> 


<cellmonitor id="6" attr="head"> 
<csv file="head.csv" label="head"></csv> 
</cellmonitor> 


<lakemonitor id="101" attr="head"><csv file="stages.csv" 
label="1lo" dbint1l="43200"></csv></lakemonitor> 





<segmentmonitor id="22" attr="head"> 
<dss file="t3x30ut.dss" pn="/hse/segment_4/head//lday/calc/"> 
</dss> 

</segmentmonitor> 


<wmmonitor wmID="10" attr="flow"> 
<dss file="t3x30ut.dss" pn="/hse/wml0_P_78/flow//lday/calc/"> 
</dss> 

</wmmonitor> 


</output> 
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7.3 RSM Uncertainty Analysis 


A limited number of tools are provided with RSM to carry out uncertainty analysis related 
to the model. A limited discussion is presented here to explain the scope of the tools 
associated with RSM. Uncertainty is a key link in the chain connecting the raw data in a 
hydrologic system and the decisions made regarding issues such as construction or operation 
of components. Factors influencing the decision include the following. 


(A) Input uncertainty: One of the factors outside the model itself that affects a decision 
is the uncertainty of the data. Most hydrologic data has errors associated with them 
due to equipment failures, recording errors, interpretation errors or a number of other 
causes. Lack of spatial resolution of input data is also part of the same problem. An 
example is the poor resolution of the rainfall and ET data sets. 


(B) Parameter uncertainty: Uncertainty associated with a model itself can be partly due to 
parameter uncertainty. Poor parameter data or lack of calibration can be the reason 
for such uncertainty. Lack of spatial resolution in the available parameter data set is 
also part of the same problem. 


(C) Algorithm uncertainty: Uncertainty associated with numerical error resulting from 
truncation error, inappropriate discretizations, poorly selected algorithms etc. can 
result in this type of uncertainty. 


(D) Forecasting uncertainty: This is the uncertainty of not knowing the future data set for 
which the decisions are to be made. Rainfall for the next 30 years can be different 
from the previous 30 years, and decisions may substantially change if long periods of 
data are available. 


(E) Operational uncertainty: Even if decisions are made considering past operational rules, 
and assuming rules for the present, exact future or past operational rules can never 
be completely known or modeled. This places an additional uncertainty on the model 
output. 


(F) Performance measure uncertainty: This uncertainty indicates that even if the hydrol- 
ogy of the system can be established using a model simulation, the ecological or en- 
vironmental implications may not be known with certainty. As a result, the actual 
implications of a proposal may be substantially uncertain. 


Among the six types of uncertainty discussed, parameter uncertainty (B) and the algorithm 
uncertainty (C) are the only types investigated at some depth within SFWMD. These and 
operational uncertainty (E) are the only types closely associated with the model. The re- 
maining uncertainties are external to the model. Other activities associated with hydrologic 
model uncertainty in South Florida include: (a) conducting a model uncertainty workshop 
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by (Loucks et al., 2002); (b) results from Lal (1996) and Trimble (1997)(kcb note: 
don’t have these ref’s) on parameter uncertainties of the SFWMM and the NSM based on 
first order, Latin hypercube and Rosenbleuth methods; (c) workshop on model uncertainty 
by (Loucks et al., 2002). The method by Trimble (1997) and (Lal, 1998) involved disturb- 
ing regional parameters in a systematic way, and determine the sensitivity matrix. There 
are some documents available at the SFWMD describing previous studies carried out on the 
topic. 


Algorithm uncertainty was investigated by (Lal, 2000b) using methods related to stability 
and spectral analysis. The primary parameters used in the analysis are the dimensionless 
time step and cell size. The effects of these parameters on numerical error and run times 
were investigated during the study. 


The remaining types of uncertainty, and how to deal with them in the decision making 
process remain unknown to a great extent. However, several decision making methods can 
be adopted to avoid having to evade this problem. 


7.3.1 Existing Capabilities For Evaluating RSM Uncertainty 


The current capabilities of the RSM toolbox includes the following as described by (Lal, 
1995) and (Lal, 2000a). 


1. Tools for parameter sensitivity analysis using the first order method, and creating a 
sensitivity matrix 


2. Tools for determining singular values and vectors of the sensitivity matrix. This tool 
is capable of determining the most significant parameter groups. 


3. Tools to determine the model output uncertainty using a known input parameter data 
set. 


4. Tools to determine the parameter covariance matrix, which gives the uncertainty of 
the raw parameters in the model, for unit output uncertainty. 


5. Tools to determine the parameter correlation matrix, parameter resolution matrix and 
data ignorance matrix 


6. Tools to determine the numerical error associated with a known cell size and a time 
step. 
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7.3.2 Methods Available For Evaluating Model Results 


Considering that full evaluation of a model run and making decisions on its merits is an 
immense task, a number of interim approaches have been used in the past. Some of these 
approaches are described below. 


7.3.3 Evaluation Based On The Significance Of Differences 


One of the approaches is to compare alternatives with the same base data set. The purpose of 
this method is to determine the significance of the differences between two proposed scenarios, 
and make a decision about the incremental benefits. Methods needed to statistically quantify 
the significance of the difference are not fully developed. The advantage of this method is 
that it does not rely heavily on the accuracy of the past data. This data are assumed as a 
standard data set against which all runs are compared. 
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7.4 


RSM Graphical User Interface 


Currently, the RSM GUI is undergoing significant development. At this time, no up-to-date 
documentation is available for this manual. RSM GUI information will be published by the 
SFWMD when code development is completed. 


7.4.1 


Overview of The Current RSM GUI 


The existing RSM pre- and post-processing GUI has significant capabilities. These include: 


15. 


. Visualization of model mesh and canal segments 


. Color-flood display of cell-by-cell values and segment-based values for any value stored 


in NetCDF 


. Support for more than one NetCDF file (e.g. one of heads and one of fluxes) in the 


same GUI run 


. Postscript / PDF / PNG dumps of color-floods 

. Shapefile (vector) basemaps 

. Fast zoom/pan navigation 

. Navigation of time steps (forward / back / fast-forward / fast-back) 

. Conversion of time-step to time-stamp (and back) with ”jump to this time step” feature 


. Continuous feedback dialog — updates current color flood variable, cell / segment ids, 


spatial coordinates as mouse moves 


. Tool for computation and color flood of hydroperiod 
. Selection of data subsets for computations, based on start/end time 
. Selection of data subsets for computations based on digitized polygons 


. ” Movie” display — steps through model time steps (optionally drops PNG scenes on 


disk for AVI generation via e.g. ImageMagick) 


. Calibration tool — reads an XML file of an RSM <observations> container, then al- 


lows user to select a station for review. Computes calibration statistics with optional 
plotting via xmgrace (with VPython support planned for next version, see below) 


Well-documented ” plug-in” interface for adding tool functionality 
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7.4.2 Overview of The Early 2005 RSM GUI Development Activities 


Other GUI features are currently undergoing development including: 


1. Hydrograph generation for current colorflood variable arbitrary cells / segments 
2. 
3. 


The features currently included in the RSM GUI are: 


. Visualize Mesh 

. Color Flood Display 

. Multiple NetCDF files 
. Postscript/PDF/PNG 
. Vector Basemaps 

. Fast Zoom/Pan 

. Nav. Timesteps 

. Convert. Timesteps 

. Feedback Dialog 

. Color flood Hydroperiod 
. Start/end selection 

. Select Data by Polygon 
. Movie Display 

. Calibration Tool 


. Plug-in Interface 


Dynamic display of canal stages along a canal reach (via VPython / OpenGL) 


Support for DSS files in calibration datasets 
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. Support for ”comparison” models — loads similar NetCDF files from several model 
runs, color-floods differences or comparative statistics for the various runs. Note that 


hydrograph, etc. are supported, based on the stats 
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5. Computation of summations and averages of NetCDF values based on spatial regions 


6. Display of structures (including mouse-over feedback dialog) 


Features to be added to RSM GUI are: 


p= 


. Hydrograph generation 

2. Dynamic Display 

3. DSS Support 

4. Comparison Models 

5. Summations and Averages 


6. Mouseover Structures 
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Appendix A 


RSM Development History 


In 1994, SFWMD engineers (lead by Jayantha Obeysekera), recognized the need for a robust, 
comprehensive integrated hydrologic model to simulate flow and water management within 
the District boundaries. The need was determined because of the deficiencies of existing 
models to simulate the natural hydrologic conditions coupled with the variety of man-made 
water control and distribution structures in South Florida. As a first action to develop a new 
model, Randy Van Zee of the SFWMD worked with a New York based company RPA and 
a Colorado based company WRMI to begin formulating a new model. The first deliverables 
of these groups was termed the South Florida Regional Simulation Model SFRSM. The 
SFRSM was a computer code written in C++ to simulate a small region of South Florida. 
In 1995, Wasantha Lal joined the District and began working with Randy Van Zee. Lal 
began work to defend SFWMM algorithms and develop computational methods for the new 
model. Discussions were initiated at the time in the District to systematically develop a new 
regional model. 


Once the RPA product came up for review, Lal, Randy, Mark Belnap and Ken Tarboton 
wanted to take an ”in-house” approach to development. Considering the special needs of 
the district, Lal wrote a joint memo laying out a work plan, and proposed algorithms for 
the initial test code. Encouraged by the success of RPA’s first version to write hydrologic 
models using object oriented methods, Randy Van Zee wrote the first 30 lines of RSM to 
follow a FORTRAN code written by Lal to simulate a small rectangular canal. These were 
the first 30 lines of the RSM used now. 


Initially the FORTRAN version of RSM grew rapidly with overland, groundwater, canal 
and structure flow capabilities in an integrated fully implicit setting. Lal was the only 
FORTRAN author, and a multiple developer environment did not exist. Mark Belnap took 
over Randy’s 30 line code and created the first object design of RSM, and expanded the 
code to give the same results given by the FORTRAN code written by Lal. This design 
allowed the growth of the code with time and allowed multiple users. Work flourished 
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with gnu compilers, DTD debuggers and CVS version control. During this critical phase, 
Belnap coined terms such as water bodies and water movers to name abstract objects. This 
architecture formed the core of HSE, and allowed others to work simultaneously. Lal (Lal, 
1998) published the first paper on HSE algorithms for a 2-D implicit finite volume method, 
and added large sparse solver to solve the equations. David Welter added the first sparse 
solver PETSC to the model, to give the necessary flexibility of using a variety of solvers. 
David later added the first vertical solution, written by Ken Tarboton. This feature is called 
HPM now. The term was coined by Randy after abstracting it from the vertical solution. As 
the code became large, the FORTRAN version was abandoned, and C++ version was taken 
as the official version. Victor Kelson (currently WPA, MN) suggested to use XML to enter 
input data into the model, and Belnap had the first versions with XML working shortly. 


During second rapid growth phase of development, Randy added various time series (e.g. 
DSS) capabilities, numerous data entry formats such as index entry, NETCDF, and HPMs. 
Lal added structures, overland, groundwater, canal and lake interactions, various test cases, 
and certain types of HPMs. With inspiration from Ken Khonyha, Lal added SV converter, 
transmissivity and conveyance objects. 


The earliest applications of the model were conducted by Lal using an old Kissimmee 
data set. Later, Belnap applied HSE on Everglade National Park, and Randy, Lal and 
Belnap applied on the L-8 basin. Subsequently, Senarat applied it on Everglades National 
Park, and Maged Hussein and David Welter used it for the South West Feasibility study. 
Ruben and Eric Flaig also started applying it on a South Dada site. David Welter turned 
into a first test pilot on many new features, and started to fix many of the bugs himself. 


Two other significant contributions to RSM development effort have to do with the use 
of analytical solutions such as the one for stream-aquifer interaction so that the model can be 
verified independent of field data. Error analysis by Lal also contributed to understanding the 
proper spatial temporal resolutions to be used. Multi-layer capability is one more addition 
to the RSM by Lal during the 2001-2002 period, in preparation of the South West Feasibility 
study model. 


In preparation of the management simulation engine (MSE), Ray Santee, Paul Trimble, 
Ron Mierrau, George Hwa and Cal Neidrauer of SFWMM were consulted in early 2002 to 
understand various management aspects within the system. As a result of the consultations, 
Lal was able to extract a simple adaptive algorithm as the first management component, 
which Randy implemented into the first feedback controller (alpha). 


In September 2002 Joseph Park was hired by Randy to assist in development of the 
MSE. Joseph worked with Lal, Randy, and Dave to reformulate the existing controller into a 
water mover flow regulation design, and coined the term MSE. Based on this design, Joseph 
implemented a generic controller class, and several controllers including PID, PI-Sigmoid, 
piecewise linear transfer function, generic fuzzy controller, and a user-defined finite state 
machine were implemented as a dynamically loaded shared library. Another design decision 
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by the developers was that the MSE and the HSE should be decoupled, and that coordination 
and dynamic modification of controllers would be needed. 


Joseph designed a multi-layer control hierarchy consisting of an Event Manager running 
multiple Control Supervisory Algorithms (CSA’s), the output of which could be synthesized 
in a Decision Manager-Arbiter based on constraint and objective function input from a 
Condition Manager. The Decision Manager output would then control the behavior of the 
water mover controllers. The Event Manager and CSA’s were eventually condensed into 
supervisors, and the Condition Manager dropped. 


In the summer of 2003 Pete Loucks of Cornell University worked with the developers and 
added a LP module based on a GLPK interface to the MSE, resulting in the LP supervisor. 
Work in 2004 centered on the development of supervisors. In late 2004, based on analogy 
with the intensively used SFWMM, Randy recognized that synoptic assessment capabilities 
were needed to simplify the supervisory algorithms. Randy developed an implementation of 
the Object Routing Model supervisory control, and eventually transformed this into a set 
of assessors. Another revelation in late 2004 was the recognition by Joseph, based on input 
from Raul Novoa, Michelle Irizarry and Ray Santee, that a managerial abstraction of the 
HSE canal network was needed to consolidate and simplify the MSE interface with the HSE 
and assessors. Joseph designed and implemented an MSE Network based on standard graph 
theory abstractions, and implemented the graph supervisor capable of maxflow and mincost 
flow routing solutions. It was also recognized that the MSE network would form a natural 
data store for managerial parameters, constraints, and assessed state information relevant 
to the water mover controllers and the Water Control Units. 


Numerous applications of RSM became possible only because of some of the GUI prod- 
ucts by Clay Brown, David Welter, and Vic Kelson (RMA). One of the first products used 
as the HSE-GUI was a product developed by RTI. Clay Brown revamped the earlier version 
the first deliverable of RTI’s ARCVIEW GIS base interface, and started providing support 
to many added features of the RSM. This completely changed the way RSM was used be- 
cause of the increased size of data sets possible. In place of the TECPLOT data conversion 
program, Dave Welter started using IBM Data Explorer and initiated a contract with Vic 
Kelson to build a GUI for RSM using Python. 


Appendix B 


Primer on Using XML 


The World Wide Web Consortium (W3C) develops technologies (specifications, guidelines, 
software, and tools)to allow people to use the World Wide Web to its full potential. W3C 
is a forum for information, commerce, communication, and collective understanding of new 
technologies. The use of XML is one topic covered by W3C. Three very good XML guidance 
documents exist on the W3C web site. These documents include: 


1. An XML primer that describes the XML Schema facilities, and is oriented towards 
quickly understanding how to create schemas using the XML Schema language: W3C 
XML Primer?. 


2. An overview of the XML Schema definition language, which offers facilities for describ- 
ing the structure and constraining the contents of XML 1.0: W3C XML Structures’. 


3. An overview of the XML Schema definition language, which offers facilities for defining 
data types to be used in XML Schemas as well as other XML specifications W3C XML 
Datatypes’. 





‘http: //www.w3.org/TR/xmlschema-0/ 
“http: //www.w3.org/TR/xmlschema-1/ 
3http://www.w3.org/TR/xmlschema-2/ 
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B.1 What Is XML? 


The eXtensible Markup Language (XML) is a very flexible text format derived from the 
Standard Generalized Markup Language (SGML). XML is a meta-markup language that 
provides a format for describing structured data. XML is used to describe documents and 
data in a standardized, text-based format that can be easily transported via standard Inter- 
net protocols. XML was originally designed to meet the challenges of large-scale electronic 
publishing. Current usage of XML is now much more widespread. XML is used to manage 
data on major web sites such as Barnes and Noble, Amazon, etc, and is becoming the stan- 
dard for multi-project, multi-user data interchange. Moreover, XML is now considered to 
be the universal language for data on the Web. XML gives developers the power to deliver 
structured data from a wide variety of applications to the desktop for local computation and 
presentation. 


There are two types of XML data used in RSM: jElements;, and attributes. The <> 
nomenclature is used throughout this manual to denote XML elements, which may also be 
referred to as nodes (although we try to avoid this term in the XML context because the term 
” nodes” is also used in the context of the finite-volume gridded domain). The attributes, 
which are properties of elements, are not placed in <>, but rather they are typed normally. 
The attribute values will be enclosed in quotes. A simple example is shown below of the 
<control> element with two of its attributes (tslen and tstype): 


<control> 
tslen="15000" 
tstype="minute" 
</control> 


XML data are validated through the use of a Data Type Definition (DTD) or an XML 
Schema, so that the XML data used as input to a program can be checked before being 
used. Both the DTD and the XML schema define the data structures and data types used 
by the program that receives the XML input file and they both can validate the data in 
the XML input files. The original XML data validation standard was the DTD, but now 
the DTD standard has been largely replaced with the newer XML Schema Standard. The 
XML schema can include a variety of data fields that allow for strict data prototyping, data 
ranges (max and min, both inclusive and exclusive values), default values, whether the data 
are required or not, among other things. Although an XML schema itself is usually complex 
and somewhat difficult to read, XML parsers do a great job at extracting the data from the 
XML file. Since XML is an extensible language, it is easy to extend a schema to handle 
whatever type of data the programmer wants to include. Compared to HTML, XML data 
typing is rigidly enforced, such that data type checking and data validation are native to 
XML. The beauty of using a schema is that the data stored in XML files can be validated 
before being sent to the program that will use the data. This relieves the programmer from 
having to check the user input. In the case of RSM, which has about 700 input variables, or 
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XML attributes (268 doubles, 174 integers, and 257 string variables), that can potentially 
be used in any model, data validation is a necessary step in developing defensible models. 


Prior to RSM version 2.2.2, a DTD has been used to validate input to RSM. Due to 
inherent limitations of DTD’s in validating input, an XML schema has been written for RSM 
version 2.2.2. The schema will be maintained into the future because of its data validation 
advantages over the DTD. More specific information on the RSM DTD (see section B.2) and 
the XML Schema (see section B.3) is available. 


XML is a text-based mark up language that allows easy exchange of data. Since XML 
is self-describing, it is a natural choice for data input to RSM. The self-describing nature 
of XML means that information about the data is easily discernible. The XML schema 
employed for HSE also: 


1. Indicates how the data are structured into a hierarchy of elements and associated at- 
tributes understood by the RSM objects 


2. Indicates the usage and content of specific data items needed for RSM 


3. Provides the syntax to allow hydrologic objects to be cast as XML elements and at- 
tributes and thus interpreted correctly by the RSM. 


B.2 The RSM DTD File 


Prior to RSM version 2.2.2, the only method of validation available for RSM XML input 
files used the DTD file residing in the directory ../hse/benchmarks. This file defined 
the XML document structure with a list of legal RSM elements and attributes. When the 
XML document was processed by the XML Parser, the DTD file specified the elements and 
attributes which were valid in the XML file. Strict data typing did not occur as part of 
this validation, which means that the DTD cannot determine if the proper data types are 
being used for an attribute. Due to inherent limitations in DTD’s, XML schemas have been 
developed to allow more accurate data validation to occur on XML data sets. Starting at 
RSM version 2.2.2, an XML schema has been written to improve the validation of RSM 
input data sets. 
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B.3 The RSM XML Schema 


From RSM version 2.2.2 onward, an XML schema can be used to validate the model input 
files. This schema is located on the web and serves as the single point of reference for RSM 
input. The RSM XML data structures defined in the schema can be viewed here: Graphical 
portrayal of the RSM 2.2.2 XML Schema‘. The actual RSM XML Schema can be down- 
loaded here: Download the RSM 2.2.2 XML Schema °® 


As of February 2005, the RSM 2.2.2 schema accurately represents the available XML 
elements and attributes present in the model. The documentation of all elements and at- 
tributes is still not complete but continues to progress as time allows. The schema, since it 
is written in XML, is easier to read and understand than the RSM DTD. 


The following example shows how the RSM schema (hse_222_corrected.xsd) is called in 
RSM XML input files and used to validate model input. The <hse> tag must include the 
reference to the hse schema as shown below: 


<?xml version="1.0" encoding="UTF-8"?> 


<hse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="http://gwmftp. jacobs.com/xml_schema_corrected/ 
hse_222_corrected.xsd" version="2.2.2" > 


<control 
tslen="15000" 
tstype="minute" 
startdate="01jan1994" 
starttime="0000" 
enddate="01jan1994" 
endtime="0230" 
alpha="0.500" 
solver="PETSC" 
method="gmres" 
precond="ilu"> 

</control> 











“http: //gwmftp.jacobs.com/xml schema corrected/graphics/hse_222.html 
http: //gwmftp.jacobs.com/xml_schema_corrected /hse_222_corrected.zip 
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B.3.1 How To Convert A DTD-Based RSM Input File To An XML Schema-Based In- 
put File 


Only one change is needed to convert the DTD based XML input data file to a schema 
based XML input file that can be validated. The beginning of the DTD-based file needs 
to be changed into the proper XML format, with the proper hse version number listed. To 
update the XML data file, simply cut-out: 


<?xml version="1.0"?> 

<!DOCTYPE hse SYSTEM "../hse.dtd" [ 
]> 

<hse version="0.1"> 








and replace it with: 


<hse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xSi:noNamespaceSchemaLocation= 
"http://gwmftp. jacobs.com/xml_schema_corrected/ 
hse_222_corrected.xsd" version="2.2.2" > 


B.3.2 How To Validate RSM Input Files Against The XML Schema 


A variety of programs and web-based utilities exist for XML validation using schemas. Ex- 
amples of these include the W3C XML schema validating routine, Microsoft Visual Studio, 
XMLSPY Home, and many other programs. 


Three validation examples are demonstrated here using the W3C validating routine. The 
first case (see subsubsection B.3.2.1) demonstrates a successful validation, which means that 
all of the XML data are of the proper data type and all required data are present. The second 
case (see subsubsection B.3.2.2) demonstrates unsuccessful validation of an XML data file. 
This file contains an invalid double precision number that was intentionally entered in the 
data set. Although this data set contains invalid data it will pass a DTD validation routine 
but it will not pass the schema-based validation because the schema validation is much more 
strict with respect to data typing. The third case (see subsubsection B.3.2.3) discusses the 
validation of model input data when more than one XML input file exists. 
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B.3.2.1 Case 1: Successful Validation Of Benchmark Problem 1 Using W3C Validating Routine 


Begin by clicking here for the W3C XML schema validating routine® 


On this page, there are two forms for validating your data. The first form is for checking 
a schema which is accessible via the Web, and/or schema-validating an instance with a 
schema of your own. The second form is used if you are behind a fire wall or have a schema 
to check, which is not accessible via the Web. For validating local data files scroll down to 
use the second validation form and select your local RSM data file by browsing to it. In this 
example shown below, the Benchmark 1 case has been selected. 


<?xml version="1.0" encoding="UTF-8"?> 


<hse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xSi:noNamespaceSchemaLocation= 
"http://gwmftp. jacobs.com/xml_schema_corrected/ 
hse_222_corrected.xsd" version="2.2.2" > 


<control 
tslen="15000" 
tstype="minute" 
startdate="01jan1994" 
starttime="0000" 
enddate="01jan1994" 
endtime="0230" 
alpha="0.500" 
solver="PETSC" 
method="gmres" 
precond="ilu"> 

</control> 








<mesh> 

To save space in this document, content removed from benchmark 1 
</mesh> 
<output> 

To save space in this document, content removed from benchmark 1 


</output> 


</hse> 


The following results of the validation are returned from the W3C site. 





http: / /www.w3.org/2001/03/webdata/xsv 
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Schema validating with XSV 2.7-1 of 2004/04/01 13:40:50 

Target: file:///usr/local/XSV/xsvlog/@31924.1luploaded 
(Real name: M:\Data\models_2.2.2\hse\kcb_benchmarks\BM1\run3x3.xm1l) 

docElt: {None}hse 

Validation was strict, starting with type [Anonymous] 

schemaLocs: None -> http://gwmftp.jacobs.com/ 
xml_schema_corrected/hse_222_corrected.xsd 

The schema(s) used for schema-validation had no errors 

No schema-validity problems were found in the target 








Schema resources involved 

Attempt to load a schema document from 

http://gwmftp. jacobs.com/xml_schema_corrected/hse_222 corrected.xsd 
(source: schemaLoc) for no namespace, succeeded 





B.3.2.2 Case 2: Unsuccessful Validation Of Benchmark Problem 1 Using W3C Validating Routine 


To corrupt the input file, the letter ”I” (which looks a lot like a 1) has been placed at the 
end of the alpha input line as shown: 


alpha="0.5001" 


As shown below, this incorrect input triggers an error because alpha is defined as a 
double precision number in the schema and the value of ”0.5001” is not a valid double 
precision number. This case would be considered valid in a DTD-based validation check 
because this type of examination simply checks to see that a value exists for the alpha term. 


Schema validating with XSV 2.7-1 of 2004/04/01 13:40:50 

Target: file:///usr/local/XSV/xsvlog/@32070.1luploaded 
(Real name: M:\Data\models_2.2.2\hse\kcb_benchmarks\BM1\run3x3.xm1) 

docElt: {None}hse 

Validation was strict, starting with type [Anonymous] 

schemaLocs: None -> http://gwmftp.jacobs.com/ 
xml_schema_corrected/hse_222_corrected.xsd 

The schema(s) used for schema-validation had no errors 

1 schema-validity problem was found in the target 
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Schema resources involved 

Attempt to load a schema document from 

http://gwmftp. jacobs.com/xml_schema_corrected/hse_222_ corrected.xsd 
(source: schemaLoc) for no namespace, succeeded 





Problems with the schema-validity of the target 
file:///usr/local/XSV/xsvlog/@32070.luploaded:6:3: Invalid per cvc-attribute.1.2: 


attribute type check failed for {None}:alpha: 0.5001 is not a valid double literal 





B.3.2.3 Case 3: Validation Of Models Having More Than One XML Input File 


Currently, validation routines that check input data against a schema currently cannot au- 
tomatically validate files. An emerging technology called XInclude’ is now being promoted 
to include external files so that users can break long XML documents up into smaller pieces. 
Several RSM benchmarks do break the XML files into several pieces (i.e., Benchmark 55). 
This technology will eventually replace the current ” Entity” approach used with DTD-based 
document types as shown below. 


<?xml version="1.0" ?> 
<!DOCTYPE hse SYSTEM "../hse.dtd" [ 
<!ENTITY pseudo SYSTEM "pseudo.xml"> <- this is an external file 
that will be included by using the & command 
]> 
<hse version="0.1"> 
<control 
tslen="24" 
content removed to save space 
method="gmres" 
precond="ilu"> 
</control> 
content removed to save space 




















&pseudo; <- this includes the content of the file pseudo.xml 
... content removed to save space 
</hse> 





Thttp://www.w3.org/TR/xinclude/ 
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If XInclude is used in an XML data set, the validators do not automatically load the 
included files and check them against the schema. In this case, you must create a new XML 
data set that contains all of the XML data by loading all of the included files into one file. 
This file can then be validated. As the technology is standardized, more information will 
become available for XInclude. 


B.3.2.4 Additional XML Details 


The RSM XML input files are composed of mark-up fields and content. The mark-up fields 
describe elements and attributes and the content is the assigned values for the attributes. 
The types of attributes needed for any element depend upon the structure of the element, 
which is found in the XML schema. The schema completely defines the structure and 
relationships between all elements and their attributes. The schema may also define the 
data types, whether the data are a required input, the allowable range for the data, the 
default values, the maximum and minimum number of occurrences of any element, among 
other things. The schema is intimately tied to the objects present in the RSM source code, 
and the degree of data control entered in the schema is up to the programmer to decide. 
Although it is tempting to think of XML elements as hydrological objects in RSM, there is 
not a one-to-one correspondence between these items. 


e There are nearly 200 elements that loosely represent the primary building blocks for 
the hydrological objects in the RSM. XML elements are denoted with starting and 
ending tags. Elements can contain other elements or they can contain attributes. For 
elements containing other elements, an example using the element <mesh> would look 





like: 
<mesh> 
<geometry file="mesh3x3.2dm"> </geometry> 
<bottom> <const value="0.0"> </const> </bottom> 
<surface> <const value="500.0"> </const> </surface> 
<conveyance> 
<mannings a="1.000" detent="0.00001"></mannings> 
</conveyance> 
</mesh> 


For elements containing only attributes, an example using <control> would look 
like: 


<control> 
tslen="15000" 
tstype="minute" 
startdate="01jan1994" 
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starttime="0000" 
enddate="01jan1994" 
endtime="0230" 
alpha="0.500" 
solver="PETSC" 
method="gmres" 
precond="ilu"> 
</control> 








Note that the ">" portion of the beginning tag for <control> occurs after the 
attributes are defined, and is immediately followed by the ending tag </control>. 


e Attributes are the variables used to describe the properties of the elements. As shown in 
the second example above, attributes are placed within the opening tag of the element. 
Attribute definitions come in name=” value” pairs. For example <tslen="15000"> 
is the time step length attribute of the control element and it is assigned a value of 
15000. In XML, all attribute values must be placed within quotes. 


e There are nearly 200 elements and about 700 attributes supported in RSM. The 700 
attributes come in the form of double precision numbers (268), long integers (174), 
and text entities (257). As model development continues, the number of elements and 
attributes may change. The validation of the XML input files checks the validity of the 
double precision number and integers. The schema can also check the validity of the 
string variables by comparing the string values to an enumeration list. Most attributes 
that are string variable type in the RSM schema have enumeration lists that contain 
the allowable text strings. If a text string, other than one that is allowed and used as 
input, the XML schema validator will report this to the user as incorrect input. 


e Comments can be used in XML data sets and they begin with **<!--’’ and end 
with ‘*‘-->’’. Comments can contain any data except the literal string ‘‘--’’. 
You can place comments between mark-up anywhere in your document. 


e An XML file can be separated into several files for convenience. These files are defined 
using <!ENTITY HPMs SYSTEM "pseudo.xml">, and referred to later when nec- 
essary using &HPMs;. The file pseudo.xml1 should be placed within the directory. 
An example of this has been shown above in subsubsection B.3.2.3. 





e The XML schema contains information on Elements and Attributes. The attribute 
data types and relationships between elements are established in the schema. The 
RSM XML data structures can be viewed here®. 


e In the XML data files that are DTD-based, PCDATA means parsed character data. 
Character data consists of the text found between the start tag and the end tag of an 
XML element. PCDATA is text that will be parsed by a parser. Tags inside the text 
will be treated as mark-up and entities will be expanded. 





Shttp://gwmftp.jacobs.com/xml_ schema corrected /hse_222_corrected.html 
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e Inthe XML data files that are DT D-based, CDATA also means character data. CDATA 
is text that will not be parsed by a parser. Tags inside the text will not be treated as 
mark-up and entities will not be expanded. 


Appendix C 


Extending A 2D Model Into 3D - The XML 
<multilayer> Element 


Although the following component of HSE is functional, but is not optimally implemented. 
Additional capabilities need to be added to this portion of the code for greater flexibility in 
usage. User’s may need additional guidance in building 3D flow models. 


C.1 Overview of Building a 3D Model in RSM 


The HSE model was originally designed to perform only two-dimensional overland and 
groundwater flow simulations. However, the model has been extended to simulate fully 
three-dimensional ground water flow. This was accomplished without applying undue pres- 
sure on the existing model architecture because Darcy’s Law is easily extended from 2D to 
3D. 


Converting a 2D model to 3D is achieved by pre-processing the 3-D groundwater data 
and creating special HSE water bodies and water movers that replicate what occurs in an 
actual 3-D groundwater system. A preprocessor is used to convert the existing base cell data 
in a GMS mesh (2dm) format into a new layered data set. This consists of a new 2-D mesh 
file and new water mover file. The new water mover file is referred to in the XML file under 
the keyword <multilayer>. An example of a multilayered grid is shown in Figure C.1. 


C.1.1 2D to 3D Grid Program 


The C++ program gw3d2hse converts a base 2-D mesh data set and a layer data set into 
a second 2-D mesh data set and a water mover data set. HSE can process this new data as 
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Figure C.1: Sketch of the multi-layered grid used to solve 3-D groundwater flow. 


if it is a set of water movers to the 2-D problem. The results which are actually in 3-D have 
to be mapped to 2-D using RSM GUI tools or some other tool. The input and output files 
for the preprocessor are described below. 


C.1.1.1 Two-Dimensional Mesh File 


This is the first input file to gw3d2hse and is standard RSM 2-D mesh file described in 
section 3.2 of this manual. This grid file will be extended from 2d to 3d based on the user- 
defined layering described in subsubsubsection C.1.1.2, so the number of nodes and elements 
will be increased in the resulting grid output file. 


C.1.1.2 Added Layer File 


This file contains all the layers added to the bottom of the base mesh layer described earlier. 
The typical data set consist of data blocks, which describe layers below each base cell, started 
from top to bottom. The format is shown below with actual numbers replacing contents in 
square brackets. An example is given directly below the definitions. 


nb [base cell ID] [base cell vertical hydraulic conductivity] 
lay [top] [bot] [scl] [sc2] [hor. hyd. cond.] [vert. hyd. cond.] [d/k] 
lay [top] [bot] [scl] [sc2] [hor. hyd. cond.] [vert. hyd. cond.] [d/k] 
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Table C.1: Variables defined in the layer data input file. 






























































Tag Definition 

[base cell ID] Cell ID of the uppermost layer (i.e., the 
base cell) 

[base cell vertical Vertical hydraulic conductivity of the base 

hydraulic conductivity] cell (1/t) 

[top elevation] Elevation at the top of the layer (1) 

[bot elevation] Elevation at the bottom of the layer (1) 

[sc (unconfined) ] Storage coefficient when acting as an un- 
confined layer 

[sc (confined) ] Storage coefficient when fully saturated. 

[horizontal hydraulic Hydraulic conductivity in the horizontal 

conductivity] direction (1/t) 

[vertical hydraulic Hydraulic conductivity in the vertical di- 

conductivity] rection (1/t) 

[d/k] d/k Depth/conductivity value of thin layer 





assumed to be at the top of the layer (1/t) 











lay [top] [bot] [scl] [sc2] [hor. hyd. cond.] [vert. hyd. cond.] [d/k 
where\\ 
top = top elevation, 
bot = bottom elevation, 


scl = storage coefficient for unconfined conditions, 
sc2 = storage coefficient for confined conditions, 
vert. = vertical, \\ 

hor. = horizontal, \\ 

hyd. cond. = hydraulic conductivity, and 

elev. = elevation 


d/k = a unit of thickness (d) and hyd. cond. (k) that impedes vertical flow 


Definitions of the variables are given below. An example will follow. 





This example places two additional layers beneath base cells 5 and 14. 
Beneath cell 5, a 140 foot thick layer and a 70 foot layer are added. 
Beneath cell 14, a 60 ft and 40 ft layer are added. 

This is a highly simplified example. In most situations, 

it would be expected that laterally continuous layers 

would be added over more than 1 cell. 























nb 5 0.02 
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lay 440.0 300.0 
lay 300.0 230.0 
nb 14 0.04 

lay 400.0 340.0 
lay 340.0 300.0 


0.001 0.15 0.015 
0.001 0.15 0.015 


O O 
N N 
ome) 


WO 


0.001 0.15 0.015 
0.001 0.15 0.015 





O O 
N N 
O. 
RN 


C.1.1.3 Output 2-D Mesh File 


This file is like any other 2-D mesh file with additional cells to represent the new layers. 
This becomes the new input mesh file for the HSE model. 


C.1.1.4 Output Water Mover File 


The output watermover file from the preprocessor is to be used as an input to the model. 
The name of this file is included in the XML file as shown below. If the file is layered. dat, 
the XML input would be 


<multilayer> 
<layer file = "layered.dat"> </layer> 
</multilayer> 








C.1.2 Other Input Files And Modifications Needed For 3-D Groundwater Flow Mod- 
eling 


A number of files have to be modified when 3-D or layered groundwater flow is modeled. 
This is mainly because of the additional water bodies introduced as a result of the 3-D layers 
need some extra information. The following sections describe how properties are described 
for the additional water bodies describing the layered or 3-D formulations. 


C.1.2.1 Starting Head File <shead> 


The number of cells that have to be initialized is different with the layered cells. This has 
to be modified to include the initial heads for these cells. 
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C.1.2.2 HPM Definition File <HPM> 


The pseudo cell types for the new layered cells has to be added before a model run. However 
the new pseudo cells of the layered formulation don’t do anything internally. The pseudo 
cell behavior is introduced using the ”index entry” option. The format for the new pseudo 
cell entry type is as follows. 





<entry id ="2" label="lay"> 
<layerpc> </layerpc> 
</entry> 


C.1.2.3 Horizontal Conductance Definition File <t ransmissivity> 


The horizontal conductivity of the new layers or 3-D cells has to be added as <layered> 
type for a layered or 3D model run. The numerical values, however, will be overwritten with 
values read from the <multilayer> file. The <layered> tag defines the water bodies 
layered type so that they can be overwritten. Values of conductivity, lower layer elevation 
and upper layer elevation are all included in this file. 


<entry id="2" label="typel"> 
<layered cond = "10" lower = "300" higher = "450"> 
</layered> 


C.1.2.4 SV Converter Definition File <svconverter> 


SV converters also have to be defined for the new layer cells. The one to chose for layered 
cells is shown below. The index entry option is used for this purpose. 


<entry id="2" label="typel"> 
<layersv sccon= "0.2" scunc = "0.0002"> </layersv> 
</entry> 


C.1.3 Putting It All Together 


The file layered.dat that comes as output from the preprocessor file is shown below. 
This file gets defined in the XML file under the tag <multilayer>. The first line is a 
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plain text line that helps to keep track of the layer information for debugging. Layered of 
3-D features of the model are activated when the existence of a file is detected. 






































layer cel b_cel l_no zl z_u sc scc Hcond Vcon d/k 

base 5 0.02 

base 14 0.02 

cel 19 5 1 400 450 042 0.001 0.15 0.015 0 
cel 20 14 1 400 450 0.2 0.001 0.15 0.015 0 
cel 21 5 2 350 400 0.2 0.001 0.15 0.015 0 
cel 22 14 2 350 400 0.2 0.001 OLS 0.015 0 
geL 423) -5-3 300 350 0.2 0.001 0.15 0.015 0 
cel 24 14 3 300 350 0.2 0.001 Odd 0.015 0 
cel 25 5 4 250 300 0.2 0.001 0.15 0.015 0 
cel 2614 4 250 300 0:2 0.001 0.15 0.015 0 
cel 27 5 5 200 250 0.2 0.001 015 0.015 0 
cel 28 14 5 200 250 042 0.001 O15 0.015 0 
link 19 5 

link 21 19 

link 23 21 

link 25 23 

link 27 25 

link 20 14 

link 22 20 

link 24 22 

link 26 24 

link 28 26 








C.2 Boundary Conditions For Three-Dimensional Flow<multilayer> 


Needs to be written 


